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1  Executive  Summary 

C*r'  .  '' 

This  report  is  the  result  of  the  Q14  task  Q14001  ^Prioritized  Standards  List",  and  corresponds  to 
CDRL  A005  “Informal  Technical  Data.” 


—  This  report  provides  a  prioritized  list  of  standards  needed  to  support  the  development  of  STARS 
components.  Prior  to  specifying  the  standards  prioritization  scheme,  the  STARS  standards  profile, 
shown  in  Table  2,  was  defined.  This  profile  classifies  standards  by  functional  domains,  and  serves 
as  the  basis  for  the  prioritized  list  by  identifying  the  standards  important  to  achieving  STARS 
objectives.  In  this  report  the  Q14  task  is  called  the  the  Interface  Standards  task  and  Q14  personnel 
are  referred  to  as  the  Interface  Standards  team. 


The  prioritized  standards  list  is  partitioned  into  three  tiers:  those  standards  that  require  immediate 
development  work,  standards  that  require  active  monitoring,  and  standards  that  can  be  addressed 
by  passive  monitoring.  Table  4  on  page  17  summarizes  the  prioritized  list  and  actions  for  each 
standard  in  the  list.  Section  8  provides  more  detailed  descriptions  of  the  recommended  actions. 

For  each  standard  in  the  immediate  development  tier,  a  high-level  description  of  the  firBt  increment 
plan  of  action  is  provided.  These  actions  are  scoped  to  accommodate  various  constraints,  such  as 
maturity  of  the  standard  or  robustness  of  rehosted  implementations.  Regardless  of  the  scope  of  the 
plan  of  action,  the  goal  is  always  the  earliest  possible  availability  of  standard  virtual  interfaces  and 
implementations  for  STARS.  ,  / 

!  C 

Also  provided  in  this  report  is  a  detailed  account  of  the  data  and  anadysis  used  to  derive  the 
prioritized  list  and  plans.  Since  STARS  involvement  in  standardization  activities  will  be  required 
for  the  duration  of  the  STARS  development  tasks,  the  process  of  deriving  prioritized  lists  and  plans 
needs  to  be  repeatable  and  refinable.  The  Interface  Standards  task  process  model  for  standards 
selection  and  prioritization  is  summarized  in  Figure  1  on  page  8.  Sections  4-7  describe  key  aspects 
of  the  process. 

It  is  important  to  note  that  the  process  used  to  generate  the  prioritized  list  is  continuous.  It  is 
expected  that  the  STARS  standards  profile  will  evolve  as  critical  inputs  to  the  process,  e.g.,  porta¬ 
bility  studies,  industry  and  DoD  initiatives,  and  STARS  requirements,  are  monitored.  Thus,  the 
STARS  profile  described  in  this  report  is  a  snapshot  of  current  STARS  requirements  and  industry 
consensus  on  standards  needed  to  support  true  application  portability.  Comments  concerning  the 
STARS  profile  and  prioritized  list  are  encouraged. 


2  Introduction 


This  report  is  the  result  of  the  Interface  Standards  task  Q14001  “Prioritized  Standards  List,”  and 
corresponds  to  CDRL  A005  “Informal  Technical  Data.”  This  report  serves  several  purposes.  It 
provides: 


1.  Overall  scope  and  objectives  of  the  Interface  Standards  task 

2.  Detailed  description  of  the  standards  selection  and  evaluation  process 
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3.  Identification  and  prioritization  of  STARS  virtual  interface  standards 

4.  High-level  description  of  first-increment  Interface  Standards  tasks 

5.  Background  report  on  important  related  activities 

This  report  assumes  the  reader  is  familiar  with  the  standardization  process.  No  attempt  has  been 
made  to  define  every  term  before  use;  a  however,  glossary  of  terminology  and  acronyms  is  included 
at  the  end  of  this  report. 


3  Scope  and  Objectives 


The  Interface  Standards  task  is  the  instrument  by  which  standard  virtual  interfaces  are  migrated 
from  the  standards  community  for  use  by  STARS  developers  and  other  application  developers.  The 
scope  of  this  task  encompasses  all  standards  pertinent  to  achieving  long  range  STARS  objectives, 
regardless  of  whether  their  implementations  are  being  provided  under  other  STARS  tasks. 

To  achieve  this  objective,  long-  and  short-term  goals  must  be  balanced.  For  the  long  term,  activ¬ 
ities  necessary  to  anticipate  critical  standards  and  to  position  STARS  to  have  influence  on  these 
standards  are  emphasized,  lor  the  short  term,  activities  needed  for  the  delivery  of  Ada  imple¬ 
mentations  of  existing  standards  are  emphasized.  Neither  the  standards  world  nor  STARS  stand 
still;  both  will  evolve  and  change  over  time.  Thus,  as  new  standards  emerge,  and  as  the  STARS 
program  evolves,  long-  and  short-term  objectives  may  be  modified.  The  Interface  Standards  effort 
must  meet  the  need  for  planning  in  a  dynamic  environment,  and  must  anticipate  and  account  for 
changing  capabilities  and  requirements. 

Our  approach  to  maintaining  this  balance  is  to  establish  a  process  to  ensure  the  continuous  gauging 
and  refinement  of  long-  and  short-term  plans  and  activities  necessary  to  pursue  STARS  interests. 
This  standards  selection  process,  illustrated  in  Figure  1,  provides  an  evolving  “hit  list”  of  critical 
standards,  and  an  evaluation  of  the  anticipated  time  when  the  standard  will  be  needed.  Key  aspects 
of  this  process  are: 

•  Continuous,  active  monitoring  of  important  industry  standards  activities  related  to  construc¬ 
tion  of  open  systems  architectures 

,•  Development  and  continuous  refinement  of  reference  models  for  evaluating  existing  and  emerg¬ 
ing  standards  against  STARS  needs 

Once  critical  standards  are  identified,  development  plans  must  be  established  which  eventually 
make  available  the  standard  virtual  interfaces  and  implementations  for  STARS  use.  The  Interface 
Standards  team  takes  the  technical  lead  on  standards  vital  to  STARS  that  are  not  being  developed 
by  other  funded  tasks.  This  aggressive  technical  development  aspect  is  crucial  to  ensure  that 
important  standards  are  developed  so  they  may  be  available  within  the  STARS  Repository  before 
the  need  for  the  interfaces  arise. 

In  some  cases,  taking  the  technical  lead  implies  no  more  than  rehosting  existing  implementations.  In 
other  cases,  more  significant  development  activities  will  be  required.  For  example,  enhancements  to 
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partial  standards  implementations  may  be  required,  or  ground-breaking  activities  may  be  necessary 
to  support  later  development.  In  all  cases,  if  virtual  interfaces  are  candidates  for  standardization, 
the  Interface  Standards  team  will,  in  addition  to  its  role  as  standards  integrator,  pursue  formal 
standardization  by  the  most  appropriate  means. 

A  prioritized  list  of  standards  and  the  plans  to  pursue  these  standards  during  the  first  increment 
is  provided.  Support  for  early  STARS  usage  has  been  emphasized,  and  will  form  the  core  of  the 
technical  development  efforts.  In  addition  a  detailed  description  of  the  process  model  and  criteria 
used  to  develop  these  plans  has  been  documented  here.  The  final  report  will  re-document  the 
planning  process,  reflecting  its  evolution  throughout  the  course  of  the  first  increment. 


4  Approach 


The  Interface  Standards  task  is  based  on  the  premise  that  the  set  of  standards  of  interest  to 
STARS  will  evolve  over  time.  There  is  a  growing  trend  in  the  standards  community  to  anticipate 
emerging  trends  and  technologies.  Thus  new  and  potentially  important  standards  may  appear 
which  might  influence  STARS  development  efforts.  Also,  since  the  STARS  development  process  is 
evolutionary ,  different  standards  may  assume  more  or  less  criticality,  depending  on  where  we  are  in 
the  STARS  development.  Thus,  new  standards  may  be  identified  and  priorities  among  standards 
may  shift  as  technology  progresses  and  provides  new  opportunities  for  virtual  interface  standards,  as 
lessons-learned  during  STARS  development  emerge,  and  as  the  development  of  STARS  components 
progresses. 

The  identification  of  relevant  standards,  and  the  approach  taken  for  migrating  these  standards 
into  STARS  use,  are  separate  tasks  and  require  different  approaches.  For  purposes  of  standards 
identification,  the  Interface  Standards  team  has  taken  a  standards  reference  model  and  application 
portability  profile  approach.  For  purposes  of  plan  generation,  an  attribute-driven  approach  is 
employed. 

Reference  Model  and  Portability  Profile  Approach.  To  a  large  extent,  which  standards  are  pursued 
on  behalf  of  the  STARS  program  is  dependent  on  an  understanding  of  STARS  needs,  i.e.,  which 
functional  areas  are  important  to  address  (e.g.,  operating  systems,  database,  graphics),  and  within 
these  functional  areas  which  standards  are  relevant.  The  latter  issue  is  complicated  by  the  some¬ 
times  subtle  relationships  between  standards  within  a  functional  area,  such  as  competing  standards 
or  standards  with  overlapping  functionality.  Reference  models  and  portability  profiles  provide  a 
fratnework  for  identifying  and  interrelating  standards  of  interest  to  STARS. 

Attribute  Approach.  There  are  a  variety  of  means  of  pursuing  standards,  and  these  plans  of  pursuit 
depend  on  a  number  of  factors,  including:  maturity  of  the  standard,  available  influence  in  the 
standardization  effort,  and  timing  constraints  such  as  relevance  of  the  standard  to  STARS  short- 
and  long-term  objectives.  Such  factors  are  quantified  as  attributes  which  are  used  in  a  trade-off 
evaluation  to  determine  the  appropriate  course  of  action  for  pursuing  important  standards. 

Figure  1  provides  a  process-model  overview  of  the  relationships  between  portability  studies  and 
standards  attributes.  As  shown  in  the  figure,  the  first  major  output  is  the  STARS  Profile.  This 
profile  is  provided  in  Table  2.  It  is  the  result  of  the  assimilation  of  information  concerning  portability 
studies,  DoD  initiatives,  and  the  STARS  Architect’s  strategic  plans.  The  STARS  profile,  STARS 
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tactical  planning,  and  the  attribute  study  provide  input  into  the  evaluation  phase.  The  attribute 
study  is  described  in  Section  5  and  summarized  in  Table  3.  The  output  of  this  evaluation  is  the 
Prioritized  List  which  is  shown  in  Table  4  within  Section  6.  The  evaluation  itself  and  the  details 
of  the  Development  Tasks  are  presented  in  Section  7. 


4.1  Reference  Models  and  Portability  Studies 

One  goal  of  STARS  is  the  creation  of  applications  based  upon  a  set  of  interlocking,  cooperating 
standard  virtual  interfaces.  Unfortunately,  the  emergence  of  this  goal  was  preceded  by  an  explosive 
and  uncoordinated  emergence  of  standards.  These  standards  were  developed  as  application  needs 
were  recognized,  and  often  were  based  upon  proprietary  systems  and  solutions.  In  short,  the 
existing  set  of  standards  defined  for  information  systems  is  far  tom  interlocking:  in  addition  to 
holes  in  needed  functionality,  standards  are  often  duplicative  if  not  outright  competing. 

Recognition  of  software  application  portability  end  the  need  for  a  cohesive  set  of  standards  to 
support  portability  is  widespread;  STARS  is  just  one  of  many  programs  pursuing  this  objective. 
One  of  the  most  important  standardization  activities  underway  now  in  industry,  as  well  as  in 
the  formal  standards  world,  is  the  development  of  reference  models  and  standards  profiles;  these 
models  and  profiles  are  being  created  for  the  purpose  of  identifying  and  relating  standards  which 
are  required  to  achieve  application  portability  within  various  application  domains. 

The  standards  profiles  and  reference  models  being  developed  now  are  directly  related  to  STARS 
objectives,  and  served  (and  will  continue  to  serve)  as  crucial  input  into  the  standards  selection 
process.  The  STARS  standards  profile  is  based  on  this  related  work  and  then  adds  to  it  the  Ada 
specific  and  language-independent  standards  work  which  are  of  particular  importance  for  early 
emergence  of  STARS  components. 


4.2  Attribute  Study 

A  great  many  variables  exist  which  affect  the  manner  in  which  standards  ought  to  be  pursued. 
These  variables  can  and  should  be  identified  so  that  alternative  plans  of  action  can  be  compared 
and  evaluated;  we  represent  these  variables  as  attributes.  The  intent  is  not  so  much  to  make  plan 
evaluation  and  generation  a  deterministic  process  as  it  is  to  provide  a  measurable  rationale  for 
choosing  one  plan  over  another.  The  standards  attributes  which  have  been  identified  are:  process, 
stage,  family,  relationship,  sponsor,  completion,  domain  maturity,  standard  maturity,  availability, 
STARS  relevance,  existing  formal  and  informal  involvement  with  the  standard,  and  relative  influ¬ 
ence  on  the  standardization  process.  The  Attribute  Study  section  explains  these  terms,  and  the 
possible  values  of  each  of  these  attributes  are  shown  in  Table  3. 


4.8  Attribute  Evaluation  and  Trade-Off  Study 

Given  an  initial  STARS  standards  profile  and  a  generic  attribute  schema  to  characterize  standards, 
the  next  step  is  evaluation  of  the  attributes  for  each  standard  within  the  STARS  profile.  The  result 
of  this  evaluation  and  analysis  is  a  set  of  recommended  actions  for  each  standard. 
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Figure  It  Q14  Analyela  Proeesa  Model 
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Attributes  compete  in  the  evaluation  criteria.  For  example,  a  standard  which  is  needed  for  appli¬ 
cations  would  have  lower  priority  than  a  standard  used  for  framework  or  tools.  On  the  other  hand, 
if  the  same  standard  has  available  Ada  bindings  or  implementations,  the  low  level  of  effort  required 
to  make  an  implementation  available  in  the  STARS  Repository  may  weigh  in  favor  of  early  action. 
The  trade-off  analysis  is  the  process  of  considering  the  interaction  between  the  various  attributes 
of  a  standard  and  deciding  what  the  appropriate  action  is. 

It  is  important  to  note  that  although  the  trade-off  analysis  has  produced  the  prioritized  list  of 
activities  which  is  shown  in  Table  4,  assignment  of  priorities  does  not  imply  that  one  standard  is 
more  or  less  important  than  another.  For  instance,  it  is  meaningless  to  assert  that  CAIS-A  is  more 
or  less  important  than  POSIX  or  the  X  Window  System.  Rather,  the  ordering  reflects  the  mo6t 
cost-effective  use  of  first  increment  resources  to  achieve  short-  and  long-term  STARS  objectives. 


5  Reference  Models  and  Standards  Profiles 


Within  the  standards  community  profiles  and  reference  models  are  being  developed  which  are 
directly  related  to  STARS  objectives.  Two  appendices  provide  background  information  on  this 
work: 


•  Appendix  A,  Application  Portability  Studies  is  a  report  describing  new  work  on  ap¬ 
plication  portability  that  has  been  undertaken  within  several  standards  organizations  during 
1988. 

•  Appendix  B,  Glossary  of  Terms  provides  definitions  and  also  project  assignments  of 
selected  standards  committees. 

Background  information  on  standards  organizations  can  be  found  in  [Cuthbert  87,JTC188  ,X3SD1  88, 
X3SD2  85,X3SD4  87].  Document  references  are  not  included  in  the  bibliography,  instead  the  num¬ 
bers  of  standards  and  of  committee  documents  are  simply  noted  within  the  body  of  this  paper. 

This  section  presents  important  terminology,  tells  why  the  studies  reported  in  Appendix  A  are  of 
significance  to  STARS  SEE,  presents  the  NIST  Application  Portability  Profile,  and  concludes  with 
the  STARS  Standards  Profile  -  Version  #1. 


5.1  Standards  Terminology 

These  definitions  prepare  for  the  following  section  which  discusses  current  studies  on  application 
portability. 

JTC  1  -  Joint  Technical  Committee  #1  (JTC  1).  “JTC  1”  will  appear  in  this  document  where 
the  reader  may  expect  to  see  “ISO."  The  ISO/IEC  Joint  Technical  Committee  1  (JTC  1)  on 
Information  Technology  was  established  in  1987  by  the  two  principle  international  standards 
organizations,  the  Organization  for  International  Standardization  (ISO)  and  the  International 
Electrotechnical  Commission  (IEC). 
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NIST  -  National  Institute  of  Standards  and  Technology,  formerly  NBS.  The  National  Bureau  of 
Standards  was  renamed  to  NIST  on  August  23,  1988. 

NIST  APP  *  NIST  Application  Portability  Profile.  This  profile  was  a  starting  point  for  the 
POSIX  Guide  work  and  is  included  as  an  appendix  to  the  federal  version  of  the  POSIX 
standard,  FIPS  151. 

POSIX  -  Portable  Software  System  Interface  -  POSIX  and  its  related  standards  axe  developed  by 
IEEE  P1003  and  JTC  1  SC21  WG  15. 

POSIX  Guide  -  The  project  of  IEEE  P1003.0:  Guide  to  a  POSIX-based  Open  Systems  Archi¬ 
tecture. 

TSG-1  -  JTC  1  Technical  Study  Group  #1.  The  first  technical  study  undertaken  since  the  for¬ 
mation  of  JTC  1.  Formally  referred  to  as  the  JTC  1  Special  Working  Group  on  Strategic 
Planning  Application  Portability  Study  Group  (JTCl  SWG/SP-APSG). 

TAG/APSG  Used  to  refer  to  the  United  States  JTCl  Technical  Advisory  Group  -  Application 
Portability  Study  Group  -  the  TAG  for  TSG-1. 

XS/SPAftC/APSG  -  The  ANSI  X3/SPARC  Application  Portability  Study  Group.  A  study  on 
application  portability  undertaken  by  the  X3  Standards  Planning  and  Requirements  Com¬ 
mittee  (SPARC). 


5.2  Studies  on  Application  Portability 

Standards  requirements  of  architectures  Buch  as  the  STARS  SEE  rely  heavily  upon  guides,  profiles 
and  reference  models  from  various  standards  organizations.  Guides  and  profiles  may  specify  sets  of 
standards  to  achieve  an  open  systems  environment,  whereas  reference  models  provide  a  framework 
from  which  standards  may  be  derived.  The  National  Institute  of  Standards  and  Technology  Ap¬ 
plication  Portability  Profile  (NIST  APP)  described  in  Table  1,  is  the  basis  for  the  STARS  profile 
described  in  Table  2.  The  NIST  APP  was  evaluated  in  terms  relevant  to  STARS  requirements 
including  applicability  to  Ada  environments. 

Several  standards  organizations  have  undertaken  Btudies  of  application  portability  during  1988. 
Appendix  A  gives  a  detailed  report  on  the  statu?  of  the  work  of  these  groups.  Their  progress  will 
continue  to  be  actively  monitored  and  appropriate  features  of  their  reference  models  or  profiles  will 
be  adopted. 

The  POSIX  P1003.0  committee  is  developing  a  Guide  to  POSIX  Based  Open  System  Architecture. 
At  the  initial  meeting  of  the  POSIX  Guide  group  in  March,  1988,  there  was  an  examination  of 
the  NIST  APP.  Because  of  this  common  root  and  from  information  derived  from  reading  all  of  the 
P1003.0  documents,  the  STARS  profile  is  already  incorporating  ideas  from  the  POSIX  guide. 

The  JTC  1  has  established  an  Application  Portability  Study  Group  under  the  aegis  of  its  Special 
Working  Group  on  Strategic  Planning.  This  study  group  is  known  as  Technical  Study  Group 
#1  (TSG-1).  The  first  meeting  of  TSG-1  occurred  in  October,  1988.  Inferences  concerning  the 
direction  the  group  will  take  can  be  made  on  the  basis  of  documents  leading  up  to  that  meeting. 
The  United  States  position  is  that  the  central  task  of  the  TSG-1  should  be  the  development  of  a 
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framework,  or  model,  specifically  a  Functional  Interface  Model.  The  recommendation  is  that  the 
work  should  begin  with  a  review  of  the  current  work,  including  the  POSIX  Guide,  the  X/OPEN 
Portability  Guide,  and  the  Open  Software  Foundation  (OSF)  Application  Environment.  Then, 
a  comparison  of  current  JTC  1  work  with  the  model  will  permit  the  identification  of  relevant 
standards  which  currently  exist  or  are  under  development  in  JTC  1.  The  comparison  would  identify 
any  possible  functional  overlap  and  could  yield  recommendations  for  new  work  and/or  the  need  for 
some  reorganization  of  JTC  1  in  order  to  effectively  address  standards  requirements  for  application 
portability  (JT/88-396-AP).  Another  recommendation,  from  the  ANSI  X3/SPARC/APSG,  is  that 
subtasks  for  TSG-1  be  organized  based  on  functional  profiles  for  various  application  environments, 
such  as:  office,  commercial,  scientific,  real  time,  industrial  automation,  etc  (ANSC  APSG/88-016). 

Profiles  mandated  by  the  U.S.  government  place  further  requirements  the  STARS  profile.  The 
two  most  prominent  ones  are  the  Government  OSI  Profile  (GOSIP)  which  mandates  that  network 
applications  use  a  specific  OSI  subset  in  all  government  procurements  by  1990.  The  other,  the 
Computer  Aided  Acquisition  and  Logistics  Support  (CALS)  mandates  the  use  of  certain  data 
interchange  standards  in  future  government  procurements.  These  mandates  must  be  accommodated 
in  the  STARS  profile. 

The  STARS  standards  profile  in  Table  2  reflects  the  synthesis  of  profiles  applicable  to  STARS  and 
anticipated  application  domains.  We  expect  the  STARS  profile  to  evolve  as  the  emerging  profiles 
and/or  reference  models  from  the  POSIX  Guide  group  and  TSG-1  mature,  and  as  new  application 
domains  and  STARS  tools  are  defined. 


6  Attribute  Study 


A  number  of  attributes  must  be  considered  when  developing  a  broad  strategy  for  identifying  and 
pursuing  candidate  standards  for  insertion  into  STARS.  Many  of  these  attributes,  Buch  as  life-cycle 
stage,  are  derived  from  the  underlying  standardization  process.  STARS  recognizes,  as  evidenced 
by  the  RFP  SOW  for  Q14,  that  standards  undergo  a  lifecycle,  and  that  different  activities  must  be 
undertaken  to  pursue  standards  depending  upon  which  lifecycle  phase  applies.  Part  of  the  analysis 
phase  of  the  Interface  Standards  task  was  to  identify  the  most  critical  attributes  pertaining  to  the 
standardization  process;  these  attributes  are  discussed  in  this  section. 

Another,  orthogonal,  set  of  attributes  which  affect  the  standards  selection  process  stem  from  STARS 
requirements.  Ideally,  the  standards  available  for  insertion  into  the  STARS  repository  would  be 
well-defined  and  developed  (in  Ada),  non-overlapping,  and  tightly  inter-locked.  However,  domain 
coverage  of  available  Ada-implemented  standards  is  uneven;  further,  as  noted  earlier  in  this  report, 
the  real  world  of  standards  provides  anything  but  non-overlapping  interlocking  standard  virtual 
interfaces.  For  this  reason,  several  factors  must  be  weighed,  including:  1)  anticipated  impact 
of  a  standard  on  STARS  development,  2)  identification  of  standards  which  have  Ada  interface 
definitions  and/or  Ada  implementations,  and  3)  anticipated  time  when  standards  will  be  most 
needed  by  STARS  applications  (including  the  STARS  SEE). 

Table  3  summarizes  the  attributes  used  for  the  initial  standards  attribute  analysis.  The  remainder 
of  the  section  provides  more  detail  on  the  significance  of  these  attributes. 

Process  -  The  Process  attribute  has  two  possible  values:  consensus  and  de  facto.  A  de  facto 
industry  standard,  such  as  the  X  Window  System,  may  eventually  migrate  into  the  formal  consensus 
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Function 

Element 

Interface  Specification 

Operating  System 

Extended  POSIX 

IEEE  P1003.1  +  Extension 

Database  Management 

SQL 

FIPS  127 

IRDS 

X3.138 

(proposed  FIPS) 

Data  Interchange 

-  Graphics 

CGM 

FIPS  128 

-  Product  Data 

IGES,  PDES 

NBSIB.  88-3813 

-  Document  Processing 

SGML 

ISO  8879-1986 

ODA/ODIF 

ISO/DIS  8613 

Network  Services 

*  Data  Communications 

OSI 

GOSIP 

-  File  Management 

NFS 

IEEE  Pl003.net 

User  Interface 

X  Window  System 

X3H3.6 

Programming  Services 

C 

X3J11,  draft  X3.159 

COBOL 

FIPS  021-2 

Fortran 

FIPS  119 

Ada 

FIPS  119 

Pascal 

FIPS  109 

Table  1:  NIST  Application  Portability  Profile 
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Function  (Category) 

Element 

Specification 

Operating  System 

CAIS-A 

POSIX 

Extended  POSIX 
POSK/Ada 

(Proposed)  DOD-STD-1838A 
FIPS  151 

IEEE  1003  extensions 

IEEE  1003.5 

Database  Management 

SQL 

SQL/Ada 

IRDS 

IRDS/Ada 

FIPS  127 

competing  specifications 

X3- 138- 1988 
informal 

User  Interface 

X  Window  System 
X/Ada 

X3H3.6/88-28R2 

X3H3.6;  X3H3.4 

Network  Services 

OSI 

OSI/Ada 

TCP/IP 

FIPS  146  (GOSIP) 
informal 

MIL-STD-1778,  MIL-STD-1779 

Graphics 

GKS 

GKS/Ada 

PHIGS 

PHIGS/Ada 

GKS-3D 

GKS-3D/Ada 

CGI 

CGM 

FIPS  120 

FIPS  120 

FIPS  153 

ISO  DIS  9593-3 

ISO  8805 

JTC1/SC24  WD  N189 

ISO  DP  9639 

FIPS  128  (CALS) 

Language  Specific 

Diana 

ADL 

ARTEWG 

Ada9x 

informal 

STARS  RFP 

SIGAda  working  group 
JTC1/SC22  WG9 

Data  Interchange 

SGML 

IGES 

PDES 

ASN.l 

Procedure  Calls 
Datatypes 

MIL-M  28001  (CALS) 

MIL-D  28000  (CALS) 
consortium  (potential  CALS) 
IS  8824 

JTC1/SC22  WGll  N57 
X3T2/87-121 

Language  Independence 

Guidelines  for 

Language  Bindings  JTC1/SC22  N466 

Table  2:  STARS  Standards  Profile 
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Attribute 

Values 

Process 

de  facto, consensus 

Stage 

proposal,  reference  model,  development,  approved, 
(implementations/bindings,  (ada,  non-ada)), 
maintenance,  revision,  reaffirmation,  specification, 
informal  standardization(consortiums),  obsolete 

Family 

data  base,  graphics,  user  interface,  data  interchange, 
networking,  operating  system,  distributed  processing 

Relationship 

(standard ,( competing, overlaps,  subset , 
enabling,  complimentary)) 

Sponsor 

ISO,  X3/ANSI,  IEEE,  ANSI,  FIPS,  MIL-STD, 
informal/de  facto ,  CALS,  MAP/TOP,  X/OPEN 

Completion 

year 

Domain  Maturity 

low,  medium,  high 

Standard  Maturity 

low,  medium,  high 

Availability 

Commercial,  ((Public  Domain,  Purchase)  Prototype) 

Kftf  ‘Jk  :F5  PPTTTPMBBi 

((tools,  framework,  applications),  (Low,  Med,  High)) 

Current  Involvement 

STARS,  Unisys  Defense  Systems,  Unisys  commercial, 
none 

Influence 

none,  low,  medium,  high 

Table  3:  Standards  Attributes 

process.  Once  a  de  facto  standard  is  well  established,  conformance  to  functionality  provided  by 
existing  implementations  is  of  overriding  importance.  In  the  development  of  consensus  standards 
which  are  new  (not  migrating  de  facto  standards),  the  weight  of  good  ideas  and  hard  requirements 
may  assert  themselves  upon  the  formalization  of  the  standard.  The  Process  attribute  is  important 
for  planning  purposes  since  different  activities  are  appropriate  for  de  facto  standards  than  are 
appropriate  for  more  formal  consensus  standards.  Great  emphasis  will  be  placed  on  making  STARS- 
developed  Ada  bindings  de  facto  industry  standards;  simultaneously  there  must  be  participation 
on  language  binding  committees.  This  dual  route  is  the  strategy  for  STARS  influence  and  eventual 
migration  of  the  de  facto  Ada  binding  standards  to  more  formal  consensus  standards. 

Stage  —  This  characterizes  the  position  of  a  standard  within  a  life-cycle  model.  For  both  consensus 
and  de  facto  standards  processes,  there  are  discrete  phases  which  standards  pass  through  before 
reaching  ultimate  maturity  within  the  process.  The  amount  of  influence,  and  the  kind  of  influence 
and  expertise  needed  (i.e.,  domain,  Ada,  or  both)  depends  upon  the  life  cycle  phase. 

Family  —  Family  characterizes  the  standard  by  where  it  fits  into  the  STARS  standards  profile.  In 
some  cases  the  lattice  effect  places  a  standard  under  multiple  families.  These  cases  are  important 
to  note,  since  inter-family  standards  relationships  may  indicate  where  standards  need  to  cooperate, 
and  hence  where  additional  virtual  interfaces  are  required.  For  example,  GKS  is  related  to  the 
graphics  and  data  interchange  families  and  the  X  Window  System  is  related  to  graphics  and  user- 
interfaces.  The  intersection  of  these  systems  in  the  graphics  family  implies  the  need  to  develop  a 
strategy  for  X  and  GKS  to  act  cooperatively  within  a  workstation  environment. 
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Relationships  -  Besides  the  inter-family  relationships  described  above,  intra-family  relationships 
are  also  important.  For  example,  it  is  important  to  know  where  distinct  standards  are  competing , 
so  that  an  informed  decision  can  be  made  to  choose  either  or  both  standards  for  insertion  into 
the  STARS  repository.  Other  relationships,  e.g.,  overlaps,  subset,  complimentary,  etc.,  need  to  be 
made  explicit  so  that  cooperating  standards  can  be  developed  and  incorporated  by  STARS  in  an 
appropriate  order. 

Sponsor  -  It  is  important  to  know  the  backers  of  a  standard,  regardless  of  whether  the  standard  is 
consensus  or  de  facto.  When  competing  standards  are  being  developed  by  two  bodies,  some  notion 
of  authority  must  be  factored  in.  ANSI  standards  are  sometimes  not  identical  to  corresponding 
ISO  standards.  Suppose  the  ANSI  standardization  of  X  varies  from  the  well  established  de  facto 
standard?  Also,  sponsorship  may  come  from  DoD  and  industry  initiatives  (e.g.,  GOSEP,  CALS, 
X/OPBN).  Identifying  interest-group  interactions  is  important. 

Completion  -  Completion  date  provides  a  timeline  reference  for  gauging  standard  maturity  and 
life-cycle  phase.  For  example,  a  standard  recently  formalized  is  likely  to  be  stable  for  several  years 
(until  the  mandatory  reaffirmation). 

Domain  and  Standard  Maturity  -  Domain  maturity  corresponds  to  the  stability  of  the  tech¬ 
nology  underlying  the  standard.  The  growing  tendency  within  ANSI  and  ISO/IEC/JTC1  towards 
developing  anticipatory  standards  means  that  standards  are  emerging  for  relatively  immature  func¬ 
tional  areas;  in  such  areas,  the  life  cycle  for  a  standard  may  be  compressed  as  technology  within 
the  domain  progresses. 

Standard  maturity  describes  the  level  of  frequency  of  modifications  and  revisions  the  standard  i6 
undergoing  to  keep  abreast  of  changing  requirements  and  technology. 

Availability  -  Availability  is  a  singularly  important  attribute.  There  are  two  types  of  availability: 
Ada  interface  definitions  (bindings)  and  Ada  implementations.  Both  bindings  and  implementations 
are  important  and  they  don’t  necessarily  go  together.  An  Ada  interface  definition  can  exist  with  or 
without  an  implementation  of  that  binding;  GKS  has  a  definition  and  an  implementation,  PHIGS 
has  an  interface  definition  but  no  implementation.  On  the  other  hand  an  implementation  of  a 
standard  can  exist  without  an  interface  definition;  SGML  is  the  example.  Even  though  our  primary 
objective  is  providing  standard  virtual  interfaces  for  STARS,  the  existence  of  an  Ada  standard 
implementation  of  acceptable  quality  may  outweigh  other  attributes  in  deriding  to  rehost  a  standard 
for  STARS. 

SEE  Relevance  -  The  values  of  the  Relevance  attribute  correspond  to  three  classes  of  interface 
users:  the  SEE  framework,  SEE  tools,  and  applications.  The  framework  makes  use  of  operating 
system  services,  and  other  baseline  system  facilities  (e.g.,  X-Window).  Tools  require  interfaces  to 
support  the  development  of  SEE  applications,  e.g.,  testing  tools,  management  tools,  formal  methods 
tools,  etc.  Applications  pertain  to  interfaces  used  by  end-user  applications  developed  with  SEE 
services  and  tools. 

These  three  classes  of  interface  users  provide  a  crude  timeline,  and  thus  a  measure  of  imperativeness. 
Interfaces  required  by  the  framework  and  baseline  being  most  critical  in  early  increments;  those 
required  by  tools  most  critical  in  early  and  middle  increments;  and  those  needed  by  applications 
most  critical  in  middle  to  late  increments. 
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Current  Involvement  -  This  indicates  what  organizations  within  Unisys  and  STARS  are  actively 
involved  within  particular  standards  efforts.  The  Interface  Standards  task  needs  to  be  aware  of  the 
key  players  within  a  standard;  available  expertise  and  influence  needs  to  be  identified  and  exploited 
to  ensure  maximum  input  of  STARS  views  and  requirements  into  the  standards  process. 

The  existence  of  STARS  activities  within  a  standard  area,  as  well  as  activities  of  the  cooperating 
Primes,  must  be  made  known  for  obvious  reasons. 

Influence  —  If  the  goal  of  participation  in  standardization  activities  is  influence  on  the  emerging 
standard  (as  opposed  to  other  reasonable  goals,  such  as  acquisition  of  expertise  and  monitoring 
of  the  emerging  consensus),  cost  effective  active  participation  demands  a  reasonable  amount  of 
concrete  influence.  Unfortunately,  such  power  is  not  always  available.  Newcomers  to  standards 
within  a  mature  domain,  such  as  database  systems,  are  likely  to  be  confronted  by  an  existing 
network  of  influence.  On  the  other  hand,  even  within  stable  domains,  opportunities  for  increased 
influence  are  available  if  the  newcomer  brings  something  concrete  and  unique  to  the  table,  such  as 
an  Ada  implementation  and  a  proposed  standard  virtual  interface. 

An  understanding  of  the  limitations,  and  potential,  for  acquiring  influence  in  formal  standards  is 
necessary  for  planning  purposes. 


7  Prioritized  Standards  and  Generic  Plans 

Table  4  provides  the  STARS  Prioritized  Li6t  annotated  with  the  actions  to  be  taken  by  the  Interface 
Standards  team  during  the  first  increment.  The  prioritized  list  represents  a  partial  ordering;  three 
(3)  priority  levels  are  identified.  The  “top”  tier  identifies  standards  development  tasks;  the  middle 
tier  identifies  standards  which  are  not  vital  for  first  increment  development,  and  working/study 
groups  that  should  be  actively  monitored.  The  bottom  tier  require  no  immediate  action,  but 
STARS  should  be  kept  aware  of  developments  (passive  monitor). 

The  balance  of  the  section  describes  the  terminology  used  in  Table  4  (e.g.,  “active  monitor", 
“propose")  These  descriptions  will  put  into  context  the  actions  taken  for  standards  designated  in 
the  prioritized  list. 

As  noted  earlier,  the  Interface  Standards  team  will  take  the  technical  lead  where  important  stan¬ 
dards  are  identified  but  are  not  under  development  by  STARS  (or  elsewhere).  The  activities 
undertaken  as  technical  lead  can  be  categorized  as  development  tasks.  Development  tasks  span 
early  ground-breaking  efforts  to  rehosting  and  tuning  of  stable  Ada  implementations.  The  key  goal 
for  the  first  increment  is  more  focused  on  providing  a  critical  mass  of  virtual  interface  functionality 
for  STARS  SEE  development;  issues  of  underlying  implementation  language  are  secondary.  For 
example,  the  X  toolkit  level  interfaces  are  critically  important  for  tool  development;  such  interfaces 
will  be  required  by  tool  builders  whether  or  not  a  full-blown  Ada  implementation  of  X  (protocol 
layer  and  toolkit  layer)  is  immediately  available. 

The  kinds  of  standards  development  tasks  undertaken  in  the  first  increment  are  outlined  below; 
these  task  denotations  are  referenced  as  Standards  Interface  actions  in  later  sections.  The  task 
definitions  are  presented  in  alphabetic  order  for  ease  of  reference. 
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Standard 

Actions 

CAIS-A 

First  Tier 

participate,  rehost,  evaluate,  propose  (Lead  -  Task  Q8) 

POSIX 

participate,  propose,  white  paper 

DIANA 

port,  evaluate,  rehost,  application,  propose,  working  group 

X/Ada 

participate,  port,  evaluate,  application,  propose,  white  paper 

IRDS/Ada 

participate,  evaluate,  analysis,  propose,  white  paper 

OSI/Ada 

active  monitor,  participate,  white  paper 

TCP-IP/Ada 

rehost,  application  (Lead  -  Task  Q8;  Sub,  CSC) 

GKS/Ada 

rehost,  application  (Lead  -  Task  Q14;  Sub,  STI) 

SQL/Ada 

participate,  active  monitor 

SGML 

TSG-1 

CALS 

Guidelines  for  - 
-  Language  Bindings 
CGM,  CGI 
PHIGS/Ada 

Second  Tier 

evaluate  (Lead  -  Task  Q13) 
active  monitor 
active  monitor 

active  monitor 

active  monitor  (Q14  Sub,  STI) 
active  monitor,  standardize 

GKS-3D 

ASN.l 

IGES 

PDES 

Procedure  Calls 

Data  types 

Third  Tier 

passive  monitor 
passive  monitor 
passive  monitor 
passive  monitor 
passive  monitor 
passive  monitor 

Table  4:  STARS  Prioritized  List 
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Active  Monitor.  Active  monitoring  means  that  the  Interface  Standards  team  will  read  the 
documents  of  a  standards  committee  and,  if  appropriate,  provide  input  to  the  committee  represen¬ 
tative^).  Appendix  A  is  based  on  active  monitoring  of  a  number  of  committees  which  are  engaged 
in  application  portability  studies. 

Analysis.  Analysis  refers  to  "groundwork”  activities.  If  a  requirement  for  virtual  interfaces  is 
identified  with  no  current  implementation  available,  preliminary  investigation  is  called  for.  The 
goal  of  the  investigation  is  to  bound  the  level  of  effort  to  provide  the  interface,  and  identify  technical 
approaches  to  pursuing  development  of  the  interfaces. 

Application.  Application  drivers  will  be  developed  to  demonstrate  virtual  interfaces  prototyped 
and/or  rehosted  for  STARS.  Application  drivers  provide  a  vehicle  for  iterative  refinement  of  Ada 
bindings  implementations,  and  can  provide  a  subjective  measurement  of  the  quality  of  proposed 
Ada  bindings.  Where  a  ported  application  is  being  evaluated,  other  styles  of  application  driver, 
e.g.,  conventional  test  suite,  may  be  developed  instead. 

Evaluate.  Evaluation  of  existing  work,  either  in  Ada  or  other  languages,  provides  invaluable  input 
to  identifying  an  approach  for  rehosting  an  implementation  for  STARS.  Evaluation  will  determine  if 
an  existing  implementation  is  suitable  as  a  basis  for  further  development,  and  will  identify  trade-offs 
among  competing  implementations  and  approaches. 

Implementors  Working  Groups.  For  prototype  or  emerging  standards  implementations,  imple¬ 
mentors  working  groups  provide  valuable  hands-on  experience  and  feedback  to  the  standardization 
process.  Communication  will  be  by  electronic  mail,  where  possible.  First  increment  working  groups 
will  be  formed  initially  around  STARS  Prime  contractors  and  subcontractors,  but  will  not  restrict 
participation  of  other  persons  from  industry/academia. 

Initiate.  This  refers  to  “start-up”  activities,  such  as  lobbying  for  creation  of  formal  working  groups 
or  subcommittees.  Less  formal  activities,  such  as  creation  of  industry  mailing  lists  and  provision 
of  interface  implementations  into  the  public  domain,  are  also  possible. 

Participate.  This  refers  to  active  participation  on  formal  committees.  While  in  general  standards 
participation  should  be  viewed  as  an  avenue  for  achieving  formal  status  for  Ada  virtual  interfaces, 
direct  participation  in  standards  committees  and  working  groups  not  focused  on  Ada  issues  may 
be  necessary  to  represent  STARS  interests  on  a  more  strategic  plane  (e.g.,  POSIX  IEEE  1003.0). 

Passive  Monitor.  Passive  monitoring  means  reading  trip  reports  or  other  information  about  a 
standards  group  which  is  forwarded  to  the  Interface  Standards  team  by  Unisys  or  STARS  personnel. 
Close  contact  with  independent  Unisys  Ada  Initiative  and  Unisys  Corporate  Standards  activities, 
as  well  as  with  the  other  Primes  and  subcontractors,  will  help  ensure  that  STARS  is  informed  of 
important  developments. 

Port.  A  first  step  of  detailed  analysis  may  be  porting  of  existing  systems.  Porting  an  implemen¬ 
tation  does  not  imply  rehosting  (i.e.,  tight  integration)  to  the  STARS  SEE.  Systems  not  written 
in  Ada  may  be  ported  as  a  starting  point  for  virtual  interface  development  e.g.,  an  Ada  veneer 
interface  to  existing  non- Ada  implementations. 

Propose.  This  refers  to  attempts  to  migrate  a  given  set  of  interfaces  to  more  formal  standard¬ 
ization.  Where  a  standing  committee  exists,  Ada  interfaces  will  be  formally  proposed  (e.g.,  X3H6 


15  February  1989 


STARS-QC-00500/000/00 


X  Window  System).  Where  no  committee  exists,  the  interface  will  be  promulgated  through  work¬ 
ing  groups,  Prime  repositories,  and  "public  domain”  repositories  in  an  effort  to  achieve  de  facto 
standardization. 

Prototype.  Prototyping  activities  are  appropriate  where  preliminary  virtual  interfaces  are  de¬ 
fined.  Application  drivers  and  implementors  working  groups  provide  empirical  feedback  needed  to 
refine  the  prototype  interfaces.  Prototyping  is  the  first  6tep  towards  attempting  to  create  de  facto 
standards. 

Rehost.  If  an  implementation  is  evaluated  favorably,  it  will  be  rehosted  to  the  baseline  STARS 
SEE.  Although  rehosting  implies  tight  integration  with  the  framework  (i.e.,  CAIS-A,  POSIX),  Ada 
veneer  interfaces  (e.g.,  X  Window  System)  may  be  rehosted  as  an  intermediate  step  to  integration. 

White  Paper.  Sometimes  fundamental  issues  need  to  be  raised  and  addressed  prior  to  embarking 
on  potentially  costly  development  efforts.  In  cases  where  such  fundamental  development  tasks  need 
undertaking,  the  results  of  the  necessary  early  analysis  will  be  presented  as  white  papers.  The  goal 
of  white  papers  is  to  provide  a  motivated  and  well  researched  starting  point  for  further  action,  and 
to  encourage  early  dialog  among  interested  parties  and  domain  experts. 


8  Detailed  Analysis  and  Proposed  Actions 


This  section  provides  a  high-level  description  of  the  activities  to  be  undertaken  by  the  Interface 
Standards  team  in  the  first  increment. 

All  of  the  standards  included  in  the  STARS  standards  profile  shown  in  Table  2  are  considered 
important  to  the  STARS  program.  While  the  trade-off  analyses  described  in  this  section  have 
produced  the  prioritized  list  of  activities  which  is  shown  in  Table  4,  the  assignment  of  priorities  does 
not  imply  that  one  standard  is  more  or  less  important  than  smother.  For  instance,  it  is  meaningless 
to  assert  that  CAIS-A  is  more  or  Ie6s  important  than  POSIX  or  the  X  Window  System.  However, 
it  is  possible  to  assign  priorities  to  these  standards  by  identifying  those  virtual  interfaces  which 
will  have  the  most  early  impact  on  the  emerging  STARS  SEE.  Further,  it  is  possible  to  identify 
standards  not  sufficiently  mature  to  support  upcoming  demands  and  therefore  require  fundamental 
work.  The  first  increment  priorities  and  actions  result  from  the  trade-off  analysis  described  in  this 
section. 

Each  of  the  standards  in  the  first  tier  is  being  pursued  during  the  first  increment  and  is  discussed 
in  this  section  (with  the  exception  of  CAIS-A  and  TCP-IP,  which  are  being  developed  by  Q8).  For 
each  standard  the  trade-off  analysis  is  followed  by  the  statement  of  actions.  The  analysis  of  each 
standard,  based  on  its  attributes  describes  its  relevance  to  STARS,  and  the  rationale  for  undertaking 
activities  on  behalf  of  the  standard  in  the  first  increment.  The  action  section  describes  the  goals 
and  tasks  to  be  accomplished  during  the  first  increment.  The  scope  of  these  tasks  is  aggressive,  and 
is  based  upon  the  (untested)  assumption  that  the  quality  of  rehosted  work  is  sufficiently  high  to 
serve  as  a  platform  for  further  development.  Should  this  assumption  prove  false,  some  readjustment 
of  first  increment  plans  may  be  necessary. 

Trade-off  analysis  of  the  standards  which  have  been  assigned  to  the  second  and  third  tiers  are  not 
presented.  The  attributes  of  these  standards  were  such  that  they  were  assigned  lower  levels  of 
priority,  and  are  not  being  developed/implemented  during  the  first  increment. 
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8.1  POSIX 


Analysis:  POSIX 
Relevant  Attributes: 

•  process:  CONSENSUS 

•  stage:  APPROVED  (Parts)  DRAFT  (Parts) 

•  relationships:  CAIS-A 

•  sponsor:  IEEE  P1003,  JTCl  SC21  WG15 

•  domain  maturity:  (operating  systems)  HIGH 

•  standard  maturity:  LOW 

•  availability:  NONE  (some  companies  claim  conformance) 

•  relevance:  (FRAMEWORK,  HIGH),  (TOOLS,  HIGH),  (APPLICATION,  HIGH) 

•  involvement:  Unisys,  TOO  MANY  OTHERS  TO  ENUMERATE 


POSIX  has  emerged  as  a  central  facet  in  application  portability  studies  and  open  system  archi¬ 
tecture  specifications.  POSIX  is  crucial  to  STARS  as  a  means  of  supporting  portable  CAIS-A 
implementations. 

Besides  the  POSIX  Ada  bindings  working  group,  other  P1003  working  groups  are  of  interest  to 
STARS,  including:  real-time,  transaction  processing,  networking,  and  (newly  forming)  user  inter¬ 
face  extensions  to  POSIX.  The  POSIX  committee  in  time  has  taken  on  a  more  broad-based  set  of 
issues  pertinent  to  software  environments  than  specification  of  interface  standards  to  UNIX.  STARS 
must  be  involved  in  the  POSIX  committee,  and  keep  abreast  of  the  widening  POSIX  scope. 

An  additional  POSIX  activity,  the  POSIX  1003.0  Guide  to  a  POSIX-based  Open  System  Architec¬ 
ture,  is  directly  relevant  to  STARS,  since  this  group  may  well  specify  a  standards  profile  similar  to 
the  STARS  profile  described  in  this  report.  STARS  influence  and  viewpoints  must  be  visible  in  the 
1003.0  study  group  in  order  to  avoid  incompatabilities  with  Ada  requirements  and  emerging  Ada 
environments. 

Implementations  of  the  POSIX/ Ada  bindings  do  not  exist,  and  are  not  expected  to  be  approved 
until  some  time  in  1989.  However,  the  need  for  Ada  POSIX  interfaces  exists  immediately,  and 
warrants  the  specification  and  use  of  draft  Ada  POSIX  interfaces. 
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Action:  POSIX 
Relevant  Actions: 


•  participate 

•  propose 

•  white  paper 


The  goal  of  the  POSIX  action  is  earliest  stabilization  of  Ada  bindings  to  the  base  POSIX  definition, 
and  continuing  involvement  in  the  POSIX  extensions,  including  the  POSIX  GUIDE  subcommittee. 
Further,  issues  pertaining  to  POSIX  and  CAIS-A  interactions  will  be  delineated. 

Participate.  Committee  participation  will  put  STARS  in  a  position  to  have  influence  on  the  formal 
standardization  process.  This  is  especially  important  in  the  P1003.0  effort,  as  premature  standard¬ 
ization  on  a  POSIX  profile  could  seriously  inhibit  STARS  innovations.  The  Interface  Standards 
team  will  actively  participate  in  the  Ada  bindings  (P1003.5),  POSIX  Guide  (P1003.0),  networking 
(P1003.net)  and  user  interface  (Pl003.ui).  Continuous  and  active  STARS  participation  in  these 
subgroups  is  important  to  ensure  STARS  influence  in  these  areas.  In  addition,  the  Interface  Stan¬ 
dards  task  will  actively  monitor  transaction  processing  and  real-time  POSIX  extensions  (P1003.tp, 
P1003.4,  respectively). 

Propose.  Early  (anticipatory)  use  of  POSIX  Ada  bindings  will  establish  a  position  to  propose 
modifications  to  the  Ada  bindings,  as  needed,  based  upon  hard-won  experience.  The  Interface 
Standards  team  will  directly  participate  in  evaluation  of  draft  Ada  bindings  to  POSIX.  The  close 
working  relationship  between  this  team  and  the  UnisyB  Baseline  SEE  team  will  facilitate  the  com¬ 
munication  of  CAIS-A  derived  POSIX  requirements  to  the  appropriate  POSIX  working  group. 

White  Paper.  A  number  of  crucial  issues  regarding  the  relationship  of  POSIX  to  the  emerging 
STARS  SEE  have  emerged  e.g.,  the  relationship  between  POSIX  and  CAIS-A,  which  need  to 
be  addressed.  The  purpose  of  the  white  paper  will  be  to  address  the  broad  implications  of  using 
POSIX  as  a  base  portability  platform,  and  in  particular  to  address  the  relationship  of  POSIX/CAIS- 
A  interfaces,  i.e.,  which  interfaces  should  be  used  by  STARS  applications  where  there  is  overlap 
between  CAIS-A  and  POSIX. 


8.2  DIANA 


Analysis:  DIANA 


Relevant  Attributes: 


•  process:  DE  FACTO 

•  stage:  PRE-PROPOSAL 
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•  sponsor:  NONE 

•  domain  maturity:  (compiler  technology)  HIGH 

•  user:  TOOLS 

•  availability:  PUBLIC  DOMAIN  PROTOTYPE 

•  relevance:  (FRAMEWORK,  LOW),  (TOOLS,  HIGH),  (APPLICATION,  LOW) 

•  involvement:  STARS,  IDA,  Commercial  Vendors 

•  influence:  POTENTIALLY  HIGH 


DIANA  presents  an  excellent  opportunity  for  integration  of  tools  sensitive  to  Ada  syntax  and  se¬ 
mantics.  As  an  intermediate  language  representation  of  Ada,  DIANA  provides  tools  access  to  static 
semantic  attributes  of  Ada  units  stored  in  Ada  libraries.  Library-level  integration  can  significantly 
augment  the  power  of  language  sensitive  tools.  DIANA  can  be  immediately  useful  for  tool  build¬ 
ing  tasks  (Q10),  as  well  as  tasks  focused  on  developing  tools  and  methods  particularized  to  Ada 
language  support  (Q18). 

The  underlying  domain  (compiler  technology)  is  mature  and  stable.  Therefore,  although  there 
are  no  sponsors  or  concrete  virtual  interface  proposals,  early  stabilization  of  a  standard  DIANA 
interface  is  possible.  The  existence  of  a  public  domain  prototype  which  is  being  supported  by  its 
developer  is  incentive  to  pursue  further  development. 

However,  the  developer  (Bill  Easton,  Peregrin  Systems)  is  currently  in  the  process  of  modifying 
DIANA  in  order  to  take  advantages  of  lessons  learned  to  produce  a  “production  quality”  imple¬ 
mentation.  Because  of  this,  substantial  first  increment  re-work  on  the  DIANA  implementation  is 
not  warranted.  That  is,  performance  tuning  or  major  re-writes  will  not  be  cost  effective.  However, 
immediate  use  of  DIANA  is  called  for,  despite  potential  performance  problems.  Further,  proposal 
of  a  virtual  interface  standard  is  warranted. 

As  a  major  user  and  promoter  of  DIANA,  Unisys  is  in  an  excellent  position  to  drive  DIANA 
standardization  activity. 


Action:  DIANA 
Relevant  Actions: 

•  Port 

•  Evaluate 

•  Rehost 

•  Application 

•  Propose 
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•  Implementor’s  Group 


The  goal  of  the  DIANA  task  is  rehosting  of  a  public  domain  DIANA  implementation  into  the 
STARS  environment,  and  reinitiate  efforts  at  standardizing  the  DIANA  virtual  interface  via  de 
facto  standardization  process. 

Port.  The  DIANA  developed  under  the  IDA  contract  and  made  available  to  Unisys  as  STARS 
Prime  contractor  will  be  ported  and  made  available  to  other  Primes  and  subcontractors.  Where 
necessary,  minor  extensions  to  facilitate  ease  of  use  will  be  developed. 

Evaluate.  The  IDA  DIANA  implementation  will  be  evaluated  in  terms  of  characteristics  such  as 
implementation  modifiability,  clarity,  and,  most  importantly,  correctness.  The  ACVC  tests  will 
serve  as  a  basis  for  correctness  testing. 

Rehost.  If,  as  expected,  the  quality  of  the  DIANA  implementation  is  adequate,  it  will  be  rehosted 
to  the  baseline  STARS  SEE.  This  involves,  at  a  minimum,  replacing  DIANA  10  with  CAIS-A  IO. 
Additionally,  the  Unix  shell  (“csh”)  scripts  may  be  replaced  with  a  master  program  making  use  of 
CAIS-A  process  control  interfaces. 

Application.  Depending  upon  preliminary  evaluation  of  DIANA  quality,  either  of  two  types  of 
application  drivers  may  be  developed.  One  application  will  be  the  replacement  of  the  Gadfly1 
knowledge-based  testing  assistant  front-end  with  DIANA.  This  effort  is  well  scoped  since  there  is 
a  discrete  set  of  packages  in  Gadfly  to  build  an  Ada  parse  tree  as  input  to  Gadfly  inferencing; 
replacing  this  with  DIANA  will  be  straightforward,  and  will  significantly  enhance  the  prospects  for 
Gadfly  extensions.  A  second  application  driver  option  is  development  of  a  semantics  pretty  printer , 
which  will  in  effect  be  a  high-level  dump  of  DIANA  instances.  This  will  facilitate  examination  of 
DIANA  instances  resulting  from  e.g.  ACVC  tests. 

Propose.  The  DIANA  implementation’s  virtual  interface  was  inadequate  because  of  constraints 
imposed  by  a  deficient  compilation  system;  a  new  interface  shall  be  developed.  This  interface, 
based  upon  an  interface  proposed  in  the  October  1982  draft  revised  DIANA  reference  manual,  shall 
form  the  basis  of  a  proposed  standard.  The  interface  will  be  developed  and  promulgated  through 
the  DIANA  implementor/user  group.  Rapid  promulgation  of  high-quality  interfaces  to  DIANA 
will  encourage  the  emergence  of  a  DIANA  de  facto  standard.  The  widespread  use  of  this  de  facto 
standard  should  be  encouraged  as  a  means  of  achieving  Mil-Std  status  for  the  DIANA  interface. 

Working  Group.  Several  Unisys  Q-tasks  will  make  use  of  DIANA  (Q14,  Q10,  Q18).  Implemen¬ 
tors  within  these  tasks  will  be  encouraged  to  participate  in  a  working  group  to  share  experiences 
(i.e.,  bugs,  deficiencies,  extensions,  etc.)  with  DIANA.  The  other  Prime  contractors  and  their 
subcontractors  will  be  encouraged  to  participate. 


8.8  The  X  Window  System  User  Interface 
Analysis:  The  X  Window  System 
Relevant  Attributes: 

1  Under  contract  of  Naval  Research  Laboratory,  contract  N 00014-88- C-2052. 
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•  process:  DE  FACTO,  EMERGING  ANSI 

•  stage:  PROPOSAL 

•  relationships:  Xlib,  Xr,  Xt,  networking 

•  sponsor:  X3/ANSI,  X-CONSORTIUM,  STARS 

•  domain  maturity:  (windowing)  MEDIUM 

•  standard  maturity:  LOW 

•  availability:  PUBLIC  DOMAIN  “C"  PROTOTYPES  AND  ADA  BINDINGS 

•  relevance:  (FRAMEWORK,  HIGH),  (TOOLS,  HIGH),  (APPLICATION,  HIGH) 

•  influence:  POTENTIALLY  VERY  HIGH  FOR  ADA  BINDINGS 

The  importance  of  the  X  Window  System  to  STARS  cannot  be  overstated:  X  forms  the  basis  for 
SEE  tool  and  application  bit-mapped  user  interfaces.  Human  factors  aspects  compel  the  devel¬ 
opment  of  tools  which  take  advantage  of  this  workstation  technology.  It  is  absolutely  vital  that 
stable  Ada  interfaces  to  needed  X  functions  are  available  before  significant  tool-building  efforts  are 
undertaken. 

STARS  has  made  a  substantial  investment  in  X.  The  STARS  foundations  program,  via  SAIC,  has 
provided  the  Primes  with  an  Ada  binding  to  the  low-level  X  library,  Xlib ,  as  well  as  a  toolkit 
binding  to  Hewlett-Packard’s  Xr.  Each  of  these  are  thallow  bindings,  e.g.,  an  Ada  veneer  over  am 
underlying  “C”  implementation. 

Additionally,  under  the  option  phase  of  this  contract,  SAIC  »  developing  either  a  full  Ada  imple¬ 
mentation  of  Xlib,  or  a  full  Ada  implementation  of  MIT’s  toolkit,  Xt.  SAIC  is  currently  negotiating 
this  point  with  STARS. 

Unisys  has  already  integrated  the  Xlib  bindings  into  the  Ada  Command  Environment  (ACE)3 
constructed  under  a  STARS  Foundations  contract,  and  so  a  substantial  amount  of  work  necessary 
to  rehost  X  in  the  STARS  environment  has  already  been  accomplished.  However,  the  Xlib  functions 
do  not  provide  a  sufficiently  high-level  platform  for  constructing  user  interfaces.  For  these  purposes 
the  toolkit  level  bindings  are  needed.  In  fact,  even  the  toolkits  are  low-level  when  compared  to 
commercially  available  kernel-based  windowing  systems;  thus  user-interface  management  systems 
(UIMS)  are  being  developed  for  X.  UIMS  provide  a  high-level  front-end  to  toolkits.  Toolkits  are  a 
prerequisite  for  implementation  of  user-interface  generators. 

In  the  long  run,  the  Xr  bindings  made  available  by  SAIC  are  not  viable.  The  most  important 
factor  mitigating  against  the  Ada  Xr  bindings  is  that  Xr  has  been  easily  surpassed  by  the  MIT 
toolkit,  Xt,  the  emerging  consensus  standard.  In  fact,  even  Hewlett-Packard  (the  originator  of  Xr) 
has  abandoned  Xr  in  favor  of  Xt.  In  the  long  run  tools  constructed  to  conform  to  Xr  will  need 
substantial  modification  to  work  with  Xt,  since  Xr  “widgets”  (toolkit  objects)  are  constructed  using 
toolkit  “intrinsics”  (built-in  toolkit  features)  which  are  not  compatible  with  Xt  intrinsics. 

The  importance  of  Xt  to  the  STARS  SEE,  both  in  terms  of  common  tool  interfaces  and  productivity¬ 
boosting  user-interface  generators,  compels  first  increment  action  regarding  toolkit-level  interfaces. 

3Uader  contract  of  the  Office  of  Naval  Research,  contract  N00014-87-C-0743 
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Action:  The  X  Window  System 
Relevant  Actions: 


•  participate 

•  port 

•  evaluate 

•  application 

•  propose 

•  white  paper 


The  goal  of  work  on  the  X  Window  System  is  to  provide  Ada  interfaces  to  the  X  toolkit  layer  for 
use  by  the  second  increment,  to  understand  the  implications  of  mapping  object-oriented  toolkit 
specifications  and  implementations  into  Ada  specifications,  and  to  work  towards  standardization  of 
the  Ada  interfaces  to  Xlib. 

Participate.  Unisys,  at  its  own  cost  outside  the  Q14  task,  is  funding  participation  on  X3H3.4  and 
X3H3.6.  STARS  input  to  these  standards  committees  will  be  through  this  Unisys  representative 
who  will  also  serve  as  a  consultant  during  Xlib  and  X  toolkit  (if  appropriate)  bindings  design.  This 
will  put  STARS  on  the  forefront  of  Ada-X  standardization. 

Port.  The  SAIC  Xlib  and  X  toolkit  shallow  bindings  (bindings  to  the  Hewlett-Packard  X-Ray,  or 
Xr,  toolkit)  will  be  ported.  Versions  will  be  maintained  to  support  Ada  LRM  allowable  compiler 
dependencies  (e.g.,  pragma  interface). 

Evaluate.  The  SAIC  Xlib  and  Xr  toolkit  bindings  will  be  analyzed  for  bindings  methods.  Shallow 
bindings  (as  opposed  to  deep  bindings)  will  demonstrate  a  simplistic  approach  to  toolkit  level 
bindings.  However,  a  substantial  number  of  issues  concerning  the  pragmatics  of  interfacing  Ada 
data  structures  and  types  to  C  have  been  addressed  by  the  SAIC  work,  and  valuable  lessons 
learned  can  be  scavenged.  More  sophisticated  bindings  approaches  will  be  required  to  achieve 
deep  bindings,  since  the  toolkits  under  development  now  are  taking  advantage  of  features  found  in 
object  oriented  languages  such  as  C++.  Although  the  concepts  and  constructs  of  inheritance  and 
message-passing  do  have  analogues  in  Ada,  a  thoughtful  approach  to  achieving  this  mapping  will 
ensure  that  Ada  toolkit  implementations  will  keep  abreast  of  prototype  implementations  emerging 
from  the  X-consortium  and  MIT. 

Application.  Sample  application  programs  will  be  constructed  to  test  the  successful  porting 
of  Xlib  and  Xr.  These  programs  will  be  constructed  to  facilitate  reuse  of  program  features  for 
construction  of  second  increment  tool  user  interfaces. 

Propose.  Higher  quality  Ada  interfaces  (as  opposed  to  shallow  bindings)  will  be  designed  for  Xlib, 
for  the  latest  release,  Xllr3.  The  Interface  Standards  team  will  use  this  definition  as  the  basis  for 
proposed  Ada  bindings  to  Xlib.  Although  the  standards  committee  has  not  yet  taken  up  language 
binding  issues,  early  preparation  will  put  STARS  in  a  position  of  influence. 
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White  Paper.  It  is  not  dear  that  the  goal  of  language  independence  of  X  interfaces  is  being 
attained  in  the  X  Window  System  toolkit  level.  The  pressures  of  constructing  high-quality,  flexible 
toolkit  implementations  in  C  may  result  in  language  dependendes.  For  example,  the  use  of  pro¬ 
cedure  and  function  addresses  to  attach  code  fragments  to  data  structures  ( callback  routines)  does 
not  appear  to  be  in  the  spirit  of  Ada.  The  god  of  this  white  paper  will  be  to  identify  key  issues 
in  mapping  object  oriented  language  implementations  in  the  C++  family  into  Ada.  Although  the 
Xt  implementation  is  in  C  and  not  C++,  it  is  dear  that  the  C  version  is  being  “shoehorned”  into 
C++-style.  Apparent  language  dependendes  in  the  emerging  Xt  definition  will  be  identified  and 
Ada  analogs  proposed.  It  is  possible  that  even  deep  Ada  bindings  to  an  underlying  C  Xt  imple¬ 
mentation  my  be  less  appropriate  than  design  of  an  Ada-oriented  toolkit  layer;  this  eventuality  will 
be  discussed  in  the  paper. 


8.4  IRDS 
Analysis:  IRDS 
Relevant  Attributes: 


•  process:  CONSENSUS 

•  stage:  APPROVED 

•  relationships:  CAIS-A,  SQL,  DATABASE 

•  sponsor:  X3H4,  JTC1  SC21  WG3,  NIST 

•  domain  maturity:  (database)  HIGH 

•  standard  maturity:  MEDIUM 

•  availability:  PUBLIC  DOMAIN  (PARTIAL)  “C"  PROTOTYPE 

•  relevance:  (FRAMEWORK,  MEDIUM),  (TOOLS,  HIGH),  (APPLICATION,  HIGH) 

•  influence:  LOW 


An  Information  Resource  Dictionary  is  a  shareable  repository  for  a  definition  of  the  information 
(data,  processes,  users)  relevant  to  an  enterprise.  A  center  of  the  universe  notion  seems  to  be 
an  attribute  of  many  standards  bodies,  and  the  ISO  IRDS  framework  document  illustrates  this 
attribute  with  the  following  statement: 

“The  design  of  the  IRDS  standard  is  such  that  further  standards  can  be  developed  subsequently  to 
support  such  fields  of  application  as  the  following: 


1.  computer  assisted  software  engineering 

2.  system  life  cycle  and  project  management 
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3.  data  element  standardization  and  management 

4.  organizational  planning 

5.  data  administration  and  data  base  administration 

6.  distributed  processing  and  distributed  data  bases 

7.  source  and  object  library  management 

8.  software  and  hardware  configuration  management 

9.  software  testing  and  quality  assurance 

10.  documentation  and  document  administration” 


There  are  not  one  but  two  IRDS  standards  being  developed.  The  ANSI  standard  has  been  approved 
and  adopted  as  a  FIPS.  The  ISO  standard  is  following  a  different  path  and  is  a  year  or  more  away 
from  completion.  The  disagreement  between  the  the  IRDS  standards  groups  is  fundamental  and 
includes  hostility.  The  chairman  of  X3H4  which  is  responsible  for  ANSI  IRDS  has  suggested  that 
the  TAG  to  the  ISO  IRDS  be  assigned  to  X3H2,  the  database  group  which  has  developed  the  SQL 
standard. 

Both  the  ANSI  and  ISO  groups  have  developed  draft  proposed  services  interfaces  to  the  dictionary 
systems.  These  are  the  programmatic  interfaces,  Pascal  language  bindings  are  provided.  While 
both  groups  intend  to  eventually  have  bindings  to  other  languages,  as  far  as  we  have  determined 
no-one  has  indicated  interest  in  developing  Ada  Language  bindings.  NIST  has  developed  a  public 
domain  prototype  of  the  ANSI  IRDS,  using  the  command  language  interface,  written  in  C  and 
implemented  on  top  of  an  Oracle  database.  Commercial  implementation  of  the  ANSI  IRDS  are 
expected  in  the  near  future.  These  would  be  implementations  of  the  command  and  menu  interfaces 
only  since  the  ANSI  services  interface  is  not  yet  adopted. 

The  STARS  need  for  IRDS  will  not  emerge  until  late  in  the  second  or  perhaps  into  the  third 
increments,  when  the  software  engineering  processes  are  sufficiently  crystallized  to  be  modeled 
via  a  conceptual  schema.  If  the  need  for  IRDS  is  to  be  satisfied,  early  fundamental  work  on  Ada 
interfaces  to  IRDS  needs  to  begin  now.  Additionally  there  needs  to  be  close  communication  between 
the  Interface  Standards  group  and  the  system  architects  and  developers  of  the  tools  which  will  make 
use  of  an  IRDS. 


Action:  IRDS 
Relevant  Actions: 

•  participate 

•  evaluate 

•  analysis 
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•  propose 

•  white  paper 


The  goal  of  the  IRDS  task  to  begin  fundamental  activities  necessary  to  ensure  timely  insertion  of 
IRDS  systems  into  the  STARS  SEE.  Modern  IRDS  are  complex  systems,  and  the  deployment  of 
an  IRDS  in  a  CASE  context  raises  complex  issues,  e.g.  data  distribution,  security,  integrity  and 
consistency,  support  for  disparate  data  models,  relationship  with  CAIS-A  node  model,  to  name  a 
few.  Before  committing  to  an  IRDS  approach,  technical  issues  as  well  as  political  issues  (e.g.,  the 
competing,  conflicting  ANSI  and  ISO  IRDS  approaches)  need  to  be  identified  and  resolved. 

Participate.  The  Interface  Standards  task  will  participate  in  the  X3H4  IRDS  committee;  this 
participation  will  provide  STARS  with  access  to  IRDS  technical  competence,  and  will  provide 
X3H4  with  a  valuable  Ada  perspective  on  the  emerging  IRDS  service  interface  standards.  Both 
ANSI  and  ISO  IRDS  standards  will  specify  procedure  interfaces  to  IRDS  services;  an  opportunity 
for  anticipatory  Ada  standardization  exists  now. 

Other  standards  efforts  are  related  to  IRDS,  e.g.,  POSIX  1003.0  and  X3H2  (SQL).  Both  of  these 
activities  are  discussed  elsewhere  in  this  report.  The  Interface  Standards  task  will  track  the  inter¬ 
section  of  activities  in  these  committees. 

Evaluate.  We  have  acquired  the  NIST  prototype  implementation  of  the  ANSI  IRDS  with  a 
command  language  interface,  written  in  C,  and  interfaced  to  an  Oracle  database  system.  This 
implementation  will  be  evaluated  as  a  part  of  the  IRDS  analysis. 

Analysis.  The  analysis  of  IRDS  will  include  not  only  technical  approaches  to  pursuing  the  devel¬ 
opment  of  the  IRDS  modules  and  service  interfaces,  but  also  of  the  process  which  »  required  in 
order  to  encourage  a  dialog  among  interested  parties  within  the  STARS  community,  so  that  the 
IRDS  is  a  consideration  in  planning  for  other  STARS  components.  Establishment  of  thi6  dialog 
is  a  top  priority,  and  an  interim  IRDS  report  will  be  released  in  the  short  term  for  the  purpose 
of  initiating  this  dialog.  The  Interface  Standards  team  will  aggressively  seek  out  industry  experts 
within  the  Primes  and  their  subcontractors  in  order  to  identify  and  scope  IRDS/STARS  issues. 

Proposal.  The  development  of  Ada  Language  bindings  to  the  services  interface  is  a  task  which 

has  several  important  side  effects:  it  will  provide  visibility  and  credibility  for  STARS  within  the 

IRDS  standards  group,  it  will  provide  a  technical  explanation  of  IRDS  functionality  to  the  STARS 

community,  and  it  will  lay  the  foundation  for  the  adoption  of  standard  Ada  bindings. 

* 

White  Paper.  As  already  noted,  the  use  of  IRDS  in  CASE  environments  raises  fundamental 
issues  which  need  to  be  addressed.  A  byproduct  of  the  IRDS  analysis  will  be  a  STARS  white  paper 
describing  the  context  which  IRDS  can/will  occupy  within  the  STARS  program. 


6.5  OSI 
Analysis:  OSI/ Ada 
Relevant  Attributes: 
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•  process:  CONSENSUS 

•  stage:  APPROVED 

•  relationships:  CAIS-A,  POSDC,  TCP/IP  and  other  DCA  protocols 

•  sponsor:  GOSIP,  X3T5,  JTC1  SC21 

•  domain  maturity:  (networking)  HIGH 

•  standard  maturity:  HIGH 

•  relevance:  (FRAMEWORK,  HIGH),  (TOOLS,  HIGH),  (APPLICATION,  HIGH) 

•  influence:  POTENTIALLY  HIGH 


Networking  standards  have  long  been  considered  of  central  importance  to  the  construction  of  open 
systems  (hence  the  OSI  acronym,  “Open  System  Interconnection”).  The  importance  of  OSI  has 
been  recognized  by  the  federal  government;  the  Government  OSI  Profile  (GOSIP)  mandates  a 
subset  of  the  OSI  protocols  for  future  government  procurements.  Although  a  two  year  transition 
period  allows  functionally  equivalent  protocols  to  be  used  (e.g.  TCP/IP),  the  DoD  is  committed 
to  making  the  transition  from  the  DCA  TCP/IP  to  OSI  protocols  in  the  near  term. 

The  OSI  protocols  are  crucially  important,  and  will  make  possible  the  development  of  STARS 
components  distributed  across  heterogeneous  networks  and  hardware.  Although  the  DCA  protocols 
TCP  and  IP  provide  nearly  equivalent  services  to  those  provided  by  layers  4  and  3  (respectively)  of 
the  OSI  model,  reliance  upon  TCP/IP  may  result  in  a  tighter  coupling  to  protocols  that  are  being 
transitioned  out  of  use  than  is  desirable. 

The  OSI  layered  model  is  specified  in  terms  of  services  provided  by  each  layer;  the  functions  of  higher 
layers  are  based  upon  services  provided  by  lower  layers.  This  model  presents  a  dose  analog  to  Ada 
packages,  and  specification  of  OSI  via  package  specifications  would  provide  protocol  independent 
access  to  OSI.  That  is,  although  peer  processes  must  share  the  same  protocol,  the  application 
programmer  need  not  be  aware  of  which  protocol  is  in  fact  used. 

However,  there  are  important  issues  that  are  raised  by  OSI  that  need  to  be  addressed  both  within 
the  formal  standards  arena,  as  well  as  within  STARS  technical  development  teams.  Standardization 
issues  include  conflicting  views  concerning  allowing  application  access  to  lower  layers  of  OSI  (layers 
6  and  below).  Technical  issues  include  the  potential  disharmony  of  migration  to  OSI  with  existing 
TCP-based  implementations. 

The  emerging  importance  of  OSI  in  conjunction  with  the  degree  of  uncertainty  concerning  stan¬ 
dardization  and  technical  (pragmatics)  issues  indicates  that  active  monitoring,  participation,  and 
analysis  are  required  prior  to  development  of  Ada  OSI  implementations  and  bindings. 


Action:  OSI/ Ada 
Relevant  Actions: 
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•  active  monitor 

•  participate 

•  white  paper 


The  goal  of  the  OSI  task  is  identification  of  key  standardization  and  technical  issues  of  OSI  and 
GOSIP  pertinent  to  STARS  objectives,  and  development  of  a  STARS  position  on  conformance  to 
GOSIP  and  OSI. 

Active  Monitor.  The  JTC1  SC21  and  X3T5  organizations  responsible  for  the  OSI  specifications 
will  be  actively  monitored,  and  the  status  of  the  several  OSI  protocol  and  subprotocol  standards 
tracked.  This  monitoring  will  be  done  in  conjunction  with  monitoring  of  GOSIP  developments; 
although  GOSIP  is  a  FIPS,  there  is  still  a  degree  of  instability  here. 

Participate.  Committee  participation  pertains  to  the  newly  formed  POSIX  Pl003.net  networking 
group.  GOSIP  is  certain  to  play  an  important  role  in  the  emerging  POSIX  networking  discussions, 
and  active,  informed  participation  by  STARS  on  this  committee  is  needed. 

White  Paper.  Some  issues  raised  by  migration  towards  OSI  via  GOSIP  have  already  been  raised 
in  this  report.  There  are  different  interpretations  of  OSI  concerning  application  access  to  lower 
layers  of  the  OSI  model.  The  existence  of  many  TCP/IP  based  applications  argues  for  permitting 
at  a  minimum  access  to  layer  4  of  the  OSI  model;  however,  this  complicates  user  applications  since 
peer  processes  must  communicate  at  the  same  OSI  layers.  More  liberal  permissions  to  access  all 
layers  would  compound  this  problem.  This  issue  is  confronted  again  where  the  X  Window  System 
is  concerned;  X  defines  a  protocol  which,  to  be  in  strict  conformance  with  OSI,  would  need  to 
provide  layer  6  services  if  it  were  to  be  considered  (as  it  is  now  by  virtue  of  its  direct  use  of  a  layer 
4  equivalent  protocol  -  TCP)  a  layer  5  protocol.  These  and  other  issues  need  to  be  addressed  and 
analyzed;  the  results  will  appear  in  a  STARS  white  paper. 


8.6  GKS 
Analysis:  GKS/Ada 
Relevant  Attributes: 

•  process:  CONSENSUS 

•  stage:  APPROVED 

•  sponsor:  FIPS,  X3H3.5  X3H3.4,  JTCl  SC24 

•  domain  maturity:  (graphics)  HIGH 

•  standard  maturity:  HIGH 

•  availability:  PUBLIC  DOMAIN 
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•  relevance:  (FRAMEWORK,  LOW),  (TOOLS,  MED),  (APPLICATION,  HIGH) 

•  influence:  HIGH 


Functionally,  GKS  fits  into  a  number  of  STARS  standards  profile  families:  data  interchange  (em¬ 
bedded  graphics),  user  interfaces,  and  graphics.  Although  GKS  is  an  “old”  standard  (a  relative 
term  in  a  fast-paced  sector  of  the  industry),  and  is  facing  some  competition  from  more  advanced 
graphics  standards  (e.g.,  PHIGS),  it  still  has  a  niche  for  applications  which  do  not  require  the 
complexity  and  overhead  of  PHIGS. 

There  is  no  early  need  for  GKS  per  se,  since  environment  tools  in  the  early  increments  will  find 
X-graphics  sufficient.  However,  early  use  of  GKS  as  an  exploratory  vehicle  for  solving  problems 
associated  with  having  graphics  interfaces  (GKS,  PHIGS)  share  the  same  device  with  X  is  ap¬ 
propriate.  Whether  or  not  PHIGS  supersedes  GKS,  or  whether  a  new  graphics  standard  emerges 
to  replace  GKS  and  PHIGS,  the  co-existence  of  several  applications  drawing  to  the  same  window 
presents  technical  issues  which  must  be  addressed. 

Since  a  Unisys  subcontractor  (STI)  has  significant  experience  with  Ada  GKS,  and  Ada  graphics  in 
general,  early  insertion  of  GKS  into  the  STARS  SEE  via  an  X  device  driver  satisfies  two  objectives: 
1)  provide  virtual  interface  for  application  graphics  capability,  and  2)  solve  problems  of  cooperation 
between  X  and  other  graphics  systems.  It  is  clear  that  the  Unisys  use  of  X  as  the  SEE  windowing 
environment  means  that  addressing  the  interaction  between  X  and  graphics  systems  in  general  will 
be  important,  and  that  the  GKS/X  work  will  provide  an  understanding  of  these  issues. 


Action:  GKS/Ada 
Relevant  Actions: 


•  Rehost 

•  Application 

The  goal  of  the  GKS  task  is  to  rehost  GKS  to  the  STARS  SEE  via  the  X-window  system.  Besides 
providing  virtual  interfaces  for  constructing  graphical  user  interfaces,  this  task  will  address  larger 
issqes  of  integration  of  graphics  systems  into  the  X  Window  environment. 

Re  host.  The  Ada  GKS  implemented  by  STI  for  STARS  Foundations  will  be  rehosted  to  the 
baseline  SEE.  The  integration  of  GKS  will  be  accomplished  by  implementation  of  an  X-driver. 
This  will  provide  SEE  applications  with  the  capability  of  using  GKS  to  draw  on  single  X  windows, 
rather  than  needing  to  take  over  the  entire  workstation  display  area. 

Application.  STI  will  provide  an  application  demonstrating  the  successful  integration  of  GKS 
and  the  X-Window  System. 
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8.7  SQL/Ada 
Analysis:  SQL/Ada 


Relevant  Attributes: 


•  process:  CONSENSUS 

•  stage:  PROPOSAL 

•  domain  maturity:  (database)  HIGH 

•  standard  maturity:  LOW 

•  completion  date:  UNKNOWN 

•  availability:  PUBLIC  DOMAIN  (PARTIAL)  PROTOTYPE 

•  relevance:  (FRAMEWORK,  LOW),  (TOOLS,  HIGH),  (APPLICATION,  HIGH) 

•  influence:  LOW 


In  his  guide  to  the  SQL  standard,  C.J.  Date  reports  that  in  1987  there  were  fifty  or  so  SQL 
implementations  available,  no  two  of  them  were  identical  and  none  were  identical  to  standard 
SQL[CJDate  87].  Date  asserts  that  SQL  is  far  from  ideal  as  a  relational  language,  that  standard 
SQL  is  severely  deficient  in  several  respects,  yet  the  standard  exists,  vendors  are  scrambling  to 
support  it,  and  the  state  of  affairs  may  possibly  change  with  time.  The  state  of  affairs  concerning 
Ada  and  SQL  is  also  unstable  and  unsatisfactory. 

The  three  basic  approaches  are:  1)  embedded  SQL;  2)  standard  procedure  interface  method;  3) 
Ada  Module  Extensions. 

The  appendices  to  the  SQL  standard  provide  definitions  for  embedded  syntaxes.  These  are  short 
hand  for  the  equivalent  separate  module  and  host  programs  which  are  specified  in  the  standard. 
Vendors,  including  Informix,  Oracle,  and  RTI  INGRES  are  implementing  the  embedded  SQL  ap¬ 
proach  which  requires  preprocessing. 

The  standard  procedure  interface  method  was  the  approach  taken  by  the  Institude  for  Denfense 
Analyses  (IDA)  and  the  WIS  JPMO  in  developing  draft  Ada  bindings.  In  this  approach  SQL  syntax 
is  expressed  in  compilable  Ada.  Grumann  has  developed  a  prototype  implementation  of  the  WIS 
bindings. 

Under  a  STARS  Foundations  contract,  Lockheed  developed  a  prototype  implementation  using  the 
standard  procedure  interface  method.  Some  reported  disadvantages  of  the  Lockheed  implemen¬ 
tation  are  the  lack  of  support  of  joins  and  the  lack  of  support  for  dynamic  creation  of  relations. 
Another  STARS  task  (Q13)  has  responsibility  for  evaluating  the  STARS  Foundations  capabilities. 

The  SQL  Ada  Module  Extensions  (SAME)  project  is  based  on  the  SQL  module  interface  which 
is  the  official  interface  to  ISO-ANS  SQL.  In  October,  1988  the  Software  Engineering  Institute 
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issued  a  draft  version  of  its  Milestone  Report  “Guidelines  on  the  U8e  of  SAME”  for  review.  In 
October,  1988  the  first  SQL  Module  Compiler  was  delivered  to  the  Army  by  Compass,  a  subsidiary 
of  Applied  Data  Research.  On  November  7, 1988  the  Congress  Business  Daily  reported  that,  based 
on  an  unsolicited  proposal  from  Intermetrics,  the  Naval  Research  Lab  will  let  a  contract  for  the 
development  of  a  full  production  quality  implementation  of  an  SQL/ Ada  module  compiler  and  to 
support  the  SEI  committee  developing  guidelines. 

The  most  appropriate  action  for  the  Interface  Standards  task  is  to  actively  monitor  and,  where 
appropriate,  participate  in  Ada  SQL  workshops,  working  groups,  and  committee  activities.  Because 
of  the  large  number  of  Ada-SQL  developers  any  first  increment  development  activities  are  likely  to 
have  diluted  if  not  duplicative  effect.  Current  approaches  to  Ada-SQL  should  be  evaluated  and  an 
explicit  statement  of  STARS  position  on  Ada-SQL  formulated. 


Action:  SQL/ Ada 
Relevant  Actions: 

•  participate 

•  active  monitor 


The  goal  of  the  SQL  activity  is  to  formulate  a  Unisys/STARS  position  on  Ada  SQL,  and  participate 
in  the  appropriate  committees  to  apply  our  influence  on  behalf  of  this  position. 

Participate  and  Active  Monitor.  STARS,  through  the  Interface  Standards  team,  will  mon¬ 
itor  for  consensus  and  convergence  of  Ada  SQL  approaches,  and  take  action  to  incorporate  Ada 
SQL  when  the  technology  is  sufficiently  mature.  In  addition,  the  Interface  Standards  task  chief 
programmer  will  serve  as  reviewer  of  the  SEI’s  “Guidelines  for  use  of  SAME  (SQL  Ada  Module 
Extensions).” 


33 


15  February  1989 


STARS-QC-00500/000/00 


References 

[CJDate  87]  C.J.Date.  A  Guide  to  the  SQL  Standard.  Addison- Wesley,  1987. 

[Cuthbert  87]  Cuthbert,  G.  R.  An  Overview  of  Computer  Graphics  Industry  Standards.  In  24th 
Space  Conference.  Cocoa  Beach,  FL,  April  1987. 

[JTC188  ]  Directives  for  the  work  of  ISO/IEC  Joint  Technical  Commitee  1  (JTC  1)  on  In¬ 
formation  Technology.  Joint  Technical  Committee  1,  June.  ISO/TEC  JTC  1  N 
240. 

[X3SD1  88]  Master  Plan  -  XS  -  Information  Processing  Systems.  X3  Standing  Document,  Jan¬ 
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Document,  October  1985. 
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A  Application  Portability  Studies 


“This  study  will  involve  a  number  of  disciplines  and  could  have  a  broad  effect  on  information 
technology  standardization  activities  over  the  next  decade.  ” 

A  characterization  of  the  international  study  on  application  portability. 

This  appendix  is  the  result  of  Active  Monitoring  of  certain  standards  groups.  It  reports  on  the 
history,  focus,  and  October  10,  1988  status  of  the  IEEE  P1003.0,  POSIX  Guide  work  and  on  the 
application  portability  studies  related  to  the  work  of  the  JTC  1  Technical  Study  Group  #1  (TSG-1). 

Architectures  such  as  the  STARS  SEE  may  be  considered  users  of  the  standards  profiles  and/or 
reference  models  which  are  under  development  in  de  facto  and  consensus  standards  organizations. 
To  illustrate:  at  a  meeting  of  the  IEEE  1003.0  POSIX  Guide  group  last  July,  Fritz  Schultz  of 
Ford  Aerospace  presented  the  Space  Station  Information  System  (SSIS)  architecture,  including  the 
mandating  of  SSIS  standards  for  each  slot  in  the  model.  Schultz  expressed  hope  that  the  POSIX 
Guide  work  would  provide  much  of  the  framework  and  standards  selection  for  SSIS,  from  which 
SSIS  could  leverage  its  work  (P1003.0/N14,  N33).  The  POSIX  Guide  and  the  work  of  the  other 
studies  on  application  portability  can  be  expected  to  provide  similar  leverage  to  the  selection  of 
standards  for  the  STARS  SEE. 


A.l  The  Players:  Organizations  &  Individuals 

There  is  a  community  of  individuals  and  organizations  working  toward  the  development  of  sets  of 
formal  and  informal  standards  which  work  together  for  application  portability.  These  are  some  of 
the  projects  which  are  defining  application  portability  profiles,  reference  models,  or  architectures: 
the  IEEE  P1003.0  POSIX  Guide,  the  NIST  Application  Portability  Profile  ( APP)  standards  project, 
the  U.K.  Central  Computer  and  Telecommunication  Agency’s  (CCTA)  Open  Systems  Architecture 
Program,  Japan’s  JISC  Systems  Software  Interface  (SSI)  standards  project,  and  programs  of  work 
by  X/OPEN  and  the  Open  Software  Foundation  (OSF).  Most  recently,  and  most  importantly, 
there  has  been  the  establishment  of  an  Application  Portability  Study  Group  under  the  aegis  of 
the  JTC  1  Special  Working  Group  on  Strategic  Planning  (ISO/IEC/JTCl/SWG-SP/APSG).  For 
easy  reference  this  study  group  has  been  officially  designated  as  JTC  1  Technical  Study  Group  #1 
(TSG-1). 

From  the  US  perspective,  there  are  five  main  groups  working  on  application  portability.  They  are 
X3/SPARC/APSG,  JTC  1  TAG  APSG,  P1003,  JTC  1  SC22/WG15,  and  JTC1  SWG/SP-APSG 
(TSG-1).  Their  arenas  are  X3,  all  of  US,  POSIX,  POSIX  worldwide,  and  application  portability 
worldwide  respectively.  For  simplicity,  we  will  discuss  the  X3/SPARC/APSG  and  JTC  1  TAG 
APSG  work  in  the  context  of  TSG-1  and  ignore  the  international  POSIX  work  since  we  have  not 
reviewed  any  documents  from  JTC  1  SC22/WG15. 

The  POSIX  Guide  work,  by  IEEE  P  1003.0,  and  the  JTC  1  application  portability  study,  by  TSG- 
1,  were  both  initiated  during  1988  to  address  interface  standards  for  application  portability.  Both 
groups  are  meeting  in  October,  1988,  and  their  work  will  take  into  account  the  work  of  the  other 
groups  listed  above:  NIST,  OSF,  X/OPEN,  CCTA.  and  SSI.  Among  the  participants  in  the  P1003.0 
group  are  individuals  from  NIST  (chair),  X/OPEN  (document  editor),  CCTA,  OSF,  AT&T,  IBM, 
Unisys,  DEC,  and  GM.  The  US  delegation  to  TSG-1  also  has  individual  representatives. 
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There  is  an  important  intersection  of  participation  in  the  various  application  portability  studies. 
The  US  delegation  to  TSG-1  has  six  individual  members:  they  are: 


Jon  Becker  -  Unisys 

Becker  and  his  coUegue,  John  Hill  of  Unisys  are  both  members  of  the  JTC  1  TAG  APSG. 
Hill  is  the  Unisys  representative  to  X3/SPARC/APSG,  and.  a  member  of  P1003,  P1003.1 
and  P  1003.0 

Robert  Follett  -  IBM 

Follett  chairs  the  X3/SPARC/APSG. 

Jim  Isaak  -  DEC 

Isaak  is  chair  of  IEEE  P1003  and  of  P1003.1. 

Roger  Martin  -  NIST 

Martin’s  colleague,  Allen  Hankinson,  chairs  P1003.0. 

Stephen  Carpenter  -  OSF 

Carpenter  made  an  OSF  presentation  at  the  July  P1003.0  meeting. 

Jack  Veenstra  -  AT&T,  Bell  Labs 


A.2  P1003.0  -  POSIX  Guide 

The  “Guide  to  POSIX  Based  Open  System  Architecture”  being  developed  by  the  POSIX  Guide 
Working  Group,  IEEE  P1003.0,  will  clearly  be  an  important  educational  document  discussing 
existing  standards,  their  inter-relationships,  the  “holes”  where  standards  are  needed,  and  various 
de  facto  specifications  (OSF,  X/OPEN)  and  government  requirements.  Whether  the  guide  goes 
beyond  being  a  tutorial  on  standards  and  establishes  a  reference  model  or  standards  profile,  based 
on  POSIX  and  a  group  of  selected  standards,  has  not  yet  been  resolved. 

P 1003.0  is  chaired  by  Allen  Hankinson  of  NIST,  and  the  document  editor  for  the  Guide  is  Mike 
Lambert  of  X/OPEN.  The  starting  point  for  P1003.0  discussion  was  the  NIST  Application  Porta¬ 
bility  Profile  (APP),  presented  by  Hankinson  (See  Table  1).  In  the  Federal  Information  Processing 
Standards  (FIPS)  version  of  the  basic  POSIX  Standard  (P1003.1),  the  NIST  APP  appears  as  an 
appendix,  but  this  appendix  is  not  a  part  of  the  POSIX  Standard.  In  the  March,  1988,  meeting 
of  the  POSIX  Guide  group,  a  claim  was  made  that  “The  output  of  the  (POSIX  Guide)  group’s 
effort  would  be  more  than  a  paper  guide,  because  the  U.S.  Federal  computer  user  community  saw 
the  P1003.0  working  group  as  a  forum  for  establishing  a  consensus  architecture  that  would  be  the 
basis  for  future  computer  system  procurement.” 

The  October  24-28,  1988  meeting  of  IEEE  P1003  will  include  the  third  meeting  of  P 1003.0.  The 
Interface  Standards  team  has  reviewed  all  of  the  P1003.0  documents  and  will  become  active  in  this 
committee.  John  Hill  of  Unisys  is  a  member  of  the  P1003.0  committee.  Jim  Lonjers,  Unisys  STARS 
Q14  and  Q8  Manager,  is  an  active  member  of  the  POSIX  Ada  bindings  committee,  P1003.5,  and  he 
will  become  active  in  P1003.0  as  well.  Jim  Moore,  IBM  STARS  System  Architect,  is  liaison  from 
P1003.5  to  P1003.0.  Note  that  IEEE  P1003  memberships  are  individual  and  these  organizational 
designations  are  given  simply  as  reference. 
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At  the  July  P1003.0  meeting  there  were  presentations  concerning  OSF,  X/OPEN,  CCTA,  graphics 
standardization  work  (X3H3),  the  POS1X  Ada  bindings  committee  (P1003.5),  PCTE,  MAP,  SSIS, 
the  X  Window  System,  Network  Standards,  and  data  interchange  standards  such  as  SGML,  IGES, 
and  PDES. 

While  the  P1003.0  documents  have  been  an  invaluable  resource  to  the  Unisys  STARS  Q14  team,  we 
must  report  that  John  Hill  has  expressed  concern  over  the  process  (or  lack  of  it)  operating  within 
this  committee.  At  the  July  meeting  in  Denver,  Hill  expressed  his  concerns  in  a  formal  statement 
and  several  other  participants  have  raised  concerns  about  the  indicated  scope  and  objectives  of  the 
committee.  The  July  minutes  summarize  Hill’s  suggestions: 


1.  Adopt  a  top-down  approach  in  this  effort. 

2.  Define  terms  completely  and  agree  on  the  definitions. 

3.  Define  a  model  to  guide  the  application  portability  work. 

4.  Define  a  reasonable  decomposition  of  the  task,  considering  the  degrees  and  domains  of  porta¬ 
bility, 

5.  Formalize  the  operation  of  the  committee,  including  tracking  assigned  work  items  and  taking 
care  in  determining  consensus. 

IEEE  P1003  is  the  committee  developing  POSIX,  and  it  consists  of  the  US  TAG  to  the  international 
POSIX  group  JTC  1  SC22/WG15  (plus  all  of  its  technical  committees).  The  POSIX  work  contains 
several  projects.  The  central  work,  done  by  P1003.1,  has  produced  the  “basic  POSIX”  a  proposed 
ANSI  standard.  The  P 1003.1  draft  has  already  been  adopted  by  NIST  as  a  Federal  Information 
Processing  Standard  (FIPS  151),  with  the  NIST  APP  as  an  appendix.  Such  groups  as  OSF  and 
X/OPEN  are  expected  to  adopt  POSIX  as  a  standard.  POSIX  Ada  bindings  work  is  being  done 
by  P1003.5.  Other  P1003  committees  are  working  on  various  extensions  to  POSIX  and  three  new 
projects  will  be  considered  at  the  October  meeting.  One  of  these  projects  concerns  networking 
and  a  representative  from  MAP/TOP  has  corresponded  with  the  P1003  chairman  concerning  the 
POSIX  networking  project  and  the  existence  of  language  independent  application  interfaces  which 
have  been  developed  by  MAP/TOP.  As  indicated  in  the  OSI  action  plans,  the  Interface  Standards 
team  will  participate  in  the  work  of  the  POSIX  networking  group  as  well  as  in  the  POSIX  Ada 
Bindings  and  POSIX  Guide  working  groups. 


A.3  Technical  Study  Group  #1  (TSG-1) 

The  JTC  1  Special  Working  Group  on  Strategic  Planning  -  Application  Portability  Study  Group 
(JTC  1/SWG-SP/APSG)  also  known  as  Technical  Study  Group  #1  (TSG-1)  is  having  its  first 
meeting  in  Tokyo,  October  11-14,  1988.  The  JTC  1  resolution  establishing  TSG-1  was  based  on 
recommendations  from  two  JTC  1  special  working  groups:  the  Special  Working  Group  on  Strategic 
Planning  (SWG-SP)  and  the  Special  Working  Group  on  Software  System  Interfaces  (SWG-SSI), 
a  group  which  had  been  studying  the  Japanese  Software  System  Interfaces  (SSI)  proposal  over  a 
period  of  about  eighteen  months.  The  resolution  which  established  TSG-1  simultaneously  disbanded 


37 


15  February  1989 


STARS-QC-00500/000/00 


SWG-SSI,  accepted  the  technical  study  recommended  by  SWG-SP,  stated  that  a  particular  SWG- 
SSI  document  should  be  used  as  a  reference  document  in  the  study,  and  requested  that  Japan  would 
convene  TSG-1  and  perform  secretariat  responsibilities. 

Along  with  the  establishment  of  the  international  TSG-1,  a  corresponding  US  JTC  1  Technical  Ad¬ 
visory  Group  Application  Portability  Study  Group  (TAG/APSG)  has  come  into  being.  This  group 
appointed  the  delegates  (listed  above)  to  the  Tokyo  October  11-14  meeting,  and  developed  a  U.S. 
position  paper  in  advance  of  that  meeting.  Additionally,  an  X3  Strategic  Planning  and  Require¬ 
ments  Committee  Application  Portability  Study  Group  (X3/SPARC/APSG)  has  been  established. 
The  X3/SPARC/APSG  has  commented  on  the  TAG/APSG  position  and  made  recommendations 
for  the  organization  of  TSG-1  subtasks.  Q14  has  reviewed  documents  relating  to  TSG-1  which  have 
emanated  from  five  groups:  the  two  JTC  1  special  working  groups  which  recommended  the  forma¬ 
tion  of  TSG-1  (SWG-SP  and  SWG-SSI),  the  US  TAG/APSG  to  TSG-1,  the  X3/SPARC/APSG, 
and  JTC  1/SC21/WG7  which  is  developing  the  Basic  Reference  Model  of  Open  Distributed  Pro¬ 
cessing  (ODP).  Documents  from  these  five  groups  indicate  the  direction  and  importance  of  the 
TSG-1  work.  Following  the  first  meeting  of  TSG-1  in  October,  1988,  additional  TSG-1  documents 
will  be  reviewed  by  Q14. 


A. 3.1  TSG-1  Charter:  Special  Working  Group  on  Strategic  Planning  (SWG-SP) 

A  SWG-SP  document  (JTC  1-N236,  Annex  B)  provides  the  charter  for  the  Bcope,  task  and  method¬ 
ology  for  TSG-1.  The  following  is  a  very  dose  paraphrase  of  that  document. 


•  Technical  Study:  Standards  Necessary  to  Define  Interfaces  for  Application  Portability. 

•  Scope:  The  objective  of  standards  in  the  area  is  to  enable  users  to  project  their  invest¬ 
ment  in  application  development  by  allowing  application  programs  operating  in  one  hard¬ 
ware/operating  system  environment*  to  operate  in  another.  *For  example,  environments 
which  indude,  but  are  not  limited  to:  Operating  Systems,  Databases,  Languages,  Data  In¬ 
terchange,  Systems  Interworking,  Network  Services,  User  Interfaces. 

•  The  Task: 

Stage  A  -  REQUIREMENTS  DEFINITION 

A.l.  To  define  user  requirements  for  application  portability  by  examining  such  work  as 
<  already  exists  and  by  inviting  contributions  from  interested  parties. 

A.2.  To  describe  those  requirements  in  terms  of  functionability,  its  elements,  the  spedfic 
functions  and  the  rdated  standard  interfaces  required. 

A. 3.  To  identify  the  feasibility  and  practicability  (induding  time  scale)  of  meeting  those 

requirements  through  standardized  interfaces. 

Stage  B  •  ANALYSIS 

B. l.  To  identify  what  rdevant  standards  exist  and  what  work  is  in  progress,  identifying 

where  it  is  taking  place. 

B.2.  To  comment  on  the  relevance  and  adequacy  of  the  work. 

B.3.  To  spedfy  any  additional  work  required  involving  both  architectural  studies  and 
NWIs. 
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Stage  C  -  CONCLUSION 

C.l.  To  propose  any  modification  required  to  existing  work  programs. 

C.2.  To  suggest  to  JTC  1  SWP-SP  where  new  work  should  be  done. 

•  Methodology: 

Reports  at  the  end  of  stages  A,  B,  and  C 

Detailed  study  program  to  be  presented  to  SWP-SP  at  its  meeting  in  December,  1988 
first  iteration  of  the  tasks  in  Stage  A  to  be  completed  by  mid  1989 

A.3.2  US  TAG/ASPG  6c  TSG-1 

The  United  States  position  on  the  application  portability  study  underway  within  JTC  1  Technical 
Study  Group  #1  (TSG-1)  was  prepared  by  the  JTC  1  Technical  Advisory  Group  Application 
Portability  Study  Group  (TAG/APSG)  to  TSG-1.  The  document  (JT/88-396-AP)  is  a  draft  of  the 
US  position. 

The  US  position  is  that  the  central  task  of  the  TSG-1  shall  be  the  development  of  an  Application 
Portability  Framework,  or  Model.  This  would  begin  with  a  review  of  the  current  work,  including 
the  POSIX  Application  Portability  Guide,  the  X/OPEN  Portability  Guide,  and  the  Open  Software 
Foundation  (OSF)  Application  Environment.  Then,  a  comparison  of  current  JTC  1  work  with 
the  model  will  permit  the  identification  of  relevant  standards  which  currently  exist  or  are  under 
development  in  JTC  1.  The  comparison  would  identify  any  possible  functional  overlap  and  could 
yield  recommendations  for  new  work  and/or  the  need  for  some  reorganization  of  JTC  1  in  order  to 
effectively  address  standards  requirements  for  application  portability. 

The  statement  recommends  a  top  down  approach,  brought  together  in  a  description  of  a  functional 
interface  model.  The  position  recommends  that  the  agenda  for  the  October  meeting  should  include 
a  review  of  the  existing  work  done  in  this  area  by  the  POSIX  Guide  group  (P1003.0),  X/OPEN, 
OSF,  the  NIST  APP,  CCTA,  ECMA,  CIE/CASE,  and  vendor  architectures.  The  work  by  P1003.0, 
X/OPEN,  and  OSF  and  possibly  by  vendors  may  be  submitted  by  the  United  States.  The  posi¬ 
tion  goes  on  to  state  the  necessity  for  an  understanding  of  terms  (such  as  application,  portability, 
and  interface)  and  problem  definition  (user  issues,  technical  issues,  application  environments,  and 
standards  issues).  Following  this  preliminary  work,  the  central  task,  the  development  of  the  Appli¬ 
cation  Portability  Framework,  or  Model  could  begin.  This  task  would  include  a  review  of  current 
framework/model  work,  consideration  of  the  requirements  for  the  model,  and  then  preparation  of 
the  model.  Following  model  preparation  there  would  be  the  identification  of  relevant  standards  and 
the  identification  of  needed  new  work.  Because  of  the  breadth  of  the  study  area,  subtasks  should 
be  identified,  and  developed  by  subgroups. 

A .3 .3  X3/SPARC/ASPG  6c  TSG-1 

The  X3/SPARC  Application  Portability  Study  Group  (X3/SPARC/APSG)  recommended  to  TSG-1 
(through  the  US  JTC  1  TAG/APSG)  that  subtasks  should  be  based  on  functional  profiles  for  various 
application  environments  such  as  office,  commercial,  scientific,  realtime,  industrial  automation,  etc., 
and  that  the  subtasks  be  addressed  by  Ad  Hoc  subgroups  (APSG/88-017). 
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X3/SPARC  Software  Systems  Interface  Study  Group  (X3/SPARC/SSISG)  has  been  reconstituted 
as  the  X3/SPARC/APSG,  under  the  chairmanship  of  Robert  Foilett  of  IBM.  The  scope  and  program 
of  work  for  this  SG  has  been  defined  in  a  committee  document  (X3/SPARC/APSG/88-001).  The 
X3/SPARC/APSG  is  a  focal  point  for  X3  input  into  JTC  1  TAG/APSG.  Similarly  P1003.0  is  a 
focal  point  for  IEEE  POSIX  input  into  JTC  1  TAG/APSG  The  extent  to  which  there  will  be  a 
divergence  of  viewpoint  by  SPARC/APSG  and  IEEE  1003.0  as  these  two  groups  prepare  input  for 
JTC  1  TAG/APSG  remains  to  be  seen.  In  the  words  of  Foilett:  This  study  (TSG-1)  will  involve 
a  number  of  disciplines  and  could  have  a  broad  effect  on  information  technology  standardization 
activities  over  the  next  decade. 

Foilett  is  establishing  communication  concerning  the  X3/SPARC/APSG  with  all  X3  committees 
working  on  standards  which  will  be  involved  in  the  application  portability  work.  For  example, 
current  work  on  reference  models  for  graphics  and  Open  Distributed  Processing  (ODP)  will  intersect 
with  TSG-1  work  and  also  with  POSIX  Guide  work.  A  concern  about  the  intersection  of  graphics 
work  and  P1003.0  work  was  raised  at  the  July  P1003.0  meeting  by  George  Carson,  a  representative 
of  JTC  1/SC24,  the  international  graphics  standards  committee.  As  described  in  the  following 
sections,  the  relation  between  the  ODP  reference  model  work  and  the  application  portability  study 
has  also  been  a  matter  of  discussion. 


A.3.4  Open  Distributed  Processing  (ODP)  iz.  TSG-1 

JTC  1/SC21/WG7  which  is  developing  the  reference  model  for  Open  Distributed  Processing  (ODP) 
has  commented  on  the  relationship  of  their  work  to  the  work  of  TSG-1  in  (JTC  1/SC21/WG7  N 
019).  The  ODP  committee  states: 

•  The  (ODP)  Basic  Reference  Model  will  not  define  programmatic  interfaces,  but  will  identify 
areas  in  which  programmatic  interfaces  may  be  required. 

•  Projects  for  "ODP  standards”  to  define  programmatic  interfaces  will  need  to  be  considered 
separately. 

•  The  intention  i6  that  projects  to  define  the  standards  will  be  assigned  within  SC21. 

•  SC21/WG7  considers  that  the  relation  between  ODP  to  the  application  portability  study  is 
satisfactorily  defined  by  the  output  of  the  JTC  1  SWG-SSI,  JTC  1-N22. 

The  referenced  document  defining  a  relationship  between  ODP  and  the  application  portability 
study  is  described  in  the  following  section. 


A.S.6  TSG-1  legacy:  SWG  on  Software  Systems  Interface  (SWG-SSI) 

The  swan  song  of  SWG-SSI  was  the  development  of  a  document  (JTC  1-N22)  which  may  be  used 
as  a  reference  document  for  TSG-1.  These  are  the  recommendations  of  SWG-SSI.  They  will  not 
necessarily  be  followed  and  in  fact  that  do  not  particularly  co-indde  with  the  US  JTC  1  TAG / APSG 
recommendations  described  above. 

Area  of  Work:  Identify  functions  whose  standardization  would  contribute  to  application  porta¬ 
bility  and  specify  those  for  which: 
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1.  there  is  an  existing  JTC  1  standard  but  no  existing  language  binding; 

2.  there  are  alternative  JTC  1  standards  or  standardization  projects  which  could  be  used  to 
achieve  the  same  objective  and  are  inconsistent; 

3.  there  is  no  existing  JTC  1  standardization  effort. 


Initial  Work:  The  initial  effort  will  address  one  representative  case  in  each  of  the  three  categories 
as  identified  in  the  area  of  work.  Additional  cases  will  be  addressed  as  the  needs  are  identified.  At 
this  time  no  new  work  items  are  being  proposed,  but  identification  of  some  new  work  items  at  a 
later  stage  is  not  precluded.  The  three  representative  cases  are: 


1.  Open  Systems  Interconnection  (OSI).  Language-independent  interfaces  will  be  identified  for 
selected  OSI  Application  Service  Elements  (ASE)  and  the  binding  of  those  interfaces  to  spe¬ 
cific  languages(s)  will  be  recommended. 

2.  Windowing.  Work  on  windowing  and  related  topics  is  under  way  in  a  number  of  JTC  1 
committees.  Specific  areas  of  overlap  will  be  identified  and  recommendations  will  be  made  to 
JTC  1  as  to  the  resolution  of  any  inconsistencies. 

3.  Multi-byte  Character  Handling.  Functions  and  services  will  be  identified  for  generic  multi¬ 
byte  character  set  handling.  Recommendations  will  be  made  for  incorporating  these  functions 
and  services  into  appropriate  JTC  1  standards. 


ODP  relationship: 

1.  In  identifying  interfaces  required  for  application  portability  one  input  would  be  the  current 
state  of  the  ODP  reference  model. 

2.  If  interfaces  are  identified  which  are  not  yet  reflected  in  the  ODP  reference  model,  those 
interfaces  shall  be  considered  for  inclusion  in  the  ODP  reference  model. 
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B  Glossary  of  Terms 

ANSI  American  National  Standards  Institute 

APP  Application  Portability  Profile,  in  particular  the  NIST  APP. 

ASN.l  Abstract  Syntax  Notation  1.  ASN.l  is  a  language  designed  for  use  as  a  descriptor  of  data 
types  and  data  values,  in  an  abstract  syntax.  This  abstract  syntax  is  mapped  to  a  bit  level 
representation  via  Basic  Encoding  Rules  (IS  8825). 

CAIS-A  Common  Apse  Interface  Set  in  Ada.  Promotes  tool  portability  /interoperability  by  pro¬ 
viding  a  standardized  set  of  calls  for  operating  system  services.  Relevant  standard:  DOD- 
STD-1838A  (proposed). 

CBEMA  Computer  Business  and  Equipment  Manufacturers  Association;  holds  the  secretariat  for 
X3. 


CCITT  International  Telegraph  and  Telephone  Consultative  Committee 

COM  Computer  Graphics  Metafile  specifies  a  file  format  suitable  for  the  description,  storage, 
and  communication  of  graphical  information  in  a  device  independent  manner.  FIPS  128  and 
ANSI  X3.122-1986. 

CGI  Common  Graphics  Interface  specifies  a  set  of  functions  for  basic  control  and  data  exchange 
between  the  device  dependent  and  device  independent  levels  of  the  graphic  system.  ISO 
DP9639. 

Common  language-independent  data  types  A  work  item  shared  by  X3T2  and  JTC  1  SC22 
WGll,  with  X3T2  taking  the  lead.  The  standard  will  define  specific  data  types  by  assigning 
identifiers  for  each  type,  specifying  the  external  physical  representation  of  each  type, the  con¬ 
ditions  under  which  each  representation  may  or  must  exist,  and  specific  mappings  between 
data  types.  The  standard  will  include  specific  procedures  for  modifying  the  range  of  data 
types  to  allow  new  types  to  be  included  in  the  standard  as  they  become  necessary. 

Common  language-independent  procedural  calling  mechanisms  A  work  item  shared  by 
X3T2  and  JTC  1 SC22  WGll  with  WGll  taking  the  lead.  The  common  language-independent 
procedural  calling  mechanisms  standard  will  identify  the  calling  environment  for  passing  pa¬ 
rameters  from  one  procedure  as  arguments  to  another.  It  will  address  remote  as  well  as  local 
calling  mechanisms,  and  is  intended  to  integrate  with  ASN.l  (IS  8824,  8825),  Presentation 
„  Service  (IS  8822)  and  Remote  Operations  Service  (IS  9072). 

COS  Corporation  for  Open  Systems  -  organization  formed  by  vendors  to  speed  the  acceptance 
and  use  of  OSI. 

DIANA  Descriptive  Intermediate  Attributed  Notation  for  Ada  -  An  intermediate  language  for 
Ada. 

DIS  Draft  International  Standard  (JTC  1) 

DP  Draft  Proposal  (JTC  1) 

DBSSG  X3/SPARC  Data  Base  Systems  Study  Group.  -  An  X3  study  group;  studying  Data  Base 
Management  Systems  and  TC97  N1526,  Reference  Model  for  DBMS  Standards. 
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ECMA  European  Computer  Manufacturer’s  Association.  Publishes  standards  on  a  wide  range  of 
topics,  effective  at  getting  its  standards  adopted  internationally.  Includes  major  US  vendors, 
such  as  Unisys,  that  manufacture  in  Europe. 

6KS  Graphical  Kernal  System.  Specifies  a  library  of  subroutines  for  an  application  programmer  to 
incorporate  within  a  program  in  order  to  produce  and  manipulate  two  dimensional  pictures. 
Promotes  portability  of  graphics  application  programs  between  different  computers.  FIPS 
120,  ANSI  X3.124-1985  and  ISO  7942. 

GKS-3D  GKS  with  3  dimensional  enhancements. 

GOSIP  Government  OSI  Profile;  A  subset  of  mandated  OSI  standards,  mandated  for  government 
procurement.  FIPS  146. 

Guidelines  for  Language  Bindings  This  is  a  technical  report  being  developed  by  JTC  1  SC22 
WGll,  Techniques  for  Bindings.  This  report,  edited  by  Madeline  Sparks,  Unisys  Ada  De¬ 
fense  Initiative,  attempts  to  capture  lessons  learned  from  past  binding  efforts,  and  to  provide 
guidelines  to  other  binding  activities.  The  intent  of  this  report  is  that  it  be  a  comprehensive 
resource  for  all  binding  efforts  within  JTC  1. 

IEC  International  Electrotechnical  Commission. 

Two  of  its  committees  were  merged  into  ISO /IEC /JTC  1. 

IGES  Initial  Graphics  Exchange  Specification  is  a  neutral  data  format  for  the  digital  exchange  of 
data  between  all  current  two  dimensional  computer  aided  design  Bystems.  MIL-D  28000 

IROS  Information  Resource  Dictionary  System.  A  database  of  information  resource  descriptions 
that  can  be  used  by  a  wide  variety  of  software  tools  used  in  the  management  of  information 
resources.  ANSI  X3.138-1988. 

ISP  International  Standard  Profile.  Organizations  which  develop  functional  standards  may  follow 
certain  procedures  and  submit  standards  to  be  adopted  as  an  ISP.  JTC  1  has  a  Special  Group 
on  Functional  Standardization  (SG-FS)  which  is  involved  in  thi6  process. 

ISDN  Integrated  Services  Digital  Network  -  the  beginning  of  standards  for  true  voice  and  data 
integration. 

ISO  International  Organization  for  Standardization. 

JTC  1  -  Joint  Technical  Committee  #1.  The  ISO/IEC  Joint  Technical  Committee  1  (JTC  1) 
on  Information  Technology  was  established  in  1987  by  the  IEC  and  the  ISO.  The  technical 
committees  forming  the  original  components  of  JTC  1  were  ISO  TC97  -  Information  Tech¬ 
nology  and  all  its  subcommittees  and  IEC  TC83  -  Information  Technology  Equipment  and 
IEC  SC47B  -  Microprocessor  systems. 

MAP /TOP  Manufacturing  Automation  Protocol  and  Technical  and  Office  Protocol.  Implemen¬ 
tations  of  OSI,  providing  OSI  protocols  for  manufacturing,  engineering,  and  office  environ¬ 
ments.  GM  originated  MAP,  Boeing  originated  TOP.  These  OSI  protocols  have  been  widely 
used  (800  companies)  over  the  past  two  years. 

NIST  -  National  Institute  of  Standards  and  Technology.  The  National  Bureau  of  Standards  (NBS) 
was  renamed  to  NIST  August  23, 1988. 
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NIST  APP  -  NIST  Application  Portability  Profile;  included  as  an  appendix  to  the  federal  POSIX 
standard,  FIPS  151. 

NWI  New  Work  Item  (JTC  1) 

OSI  Open  System  Interconnection  is  the  ISO  seven  layer  network  communication  protocol. 

OSF  Open  Software  Foundation  •  Announced  May  17,  1988.  Non-profit  R  &  D  for  design  and 
development  of  open  software.  Seven  initial  sponsors  are:  Apollo,  Groupe  Bull,  Digital, 
Hewlett-Packard,  IBM,  Nixdorf,  and  Siemans. 

Pi 003  IEEE  1003.  POSIX  standards  committee. 

P1003.0  POSIX  Guide  Working  Group 

P1003.1  Basic  POSIX.  Portable  Operating  System  for  Computer  Environments 

P1003.2  Shell  and  Application  Utility  Interface  for  Computer  Operating  System  Environ¬ 
ment 

P1003.3  Standard  for  Test  Methods  for  Measuring  Conformance  to  POSIX 

P 1003.4  Real  time  Extensions  for  Portable  Operating  Systems 

P1003.5  POSIX  Ada  Language  Binding 

P1003.6  Security  Extensions  for  POSIX 

Pl003.net  Network  Precursor  Activity  (in  formation) 

Pl003.admin  Administered  Systems  Precursor  Activity  (in  formation) 

PlOOS.tp  Transaction  Processing  (in  formation) 

PlOOS.ui  User  Interface  (in  formation) 

PDES  Product  Definition  Exchange  Specification  is  similar  to  IGES,  however  it  is  three  dimen¬ 
sional  and  geared  to  provide  communication  from  preliminary  design  through  product  man¬ 
ufacturing. 

PDISP  Proposed  Draft  International  Standard  Profile  (JTC  1) 

PHIGS  Programmers  Hierarchical  Interactive  Graphics  System  is  a  device  independent  three  di¬ 
mensional  graphical  interface  which  allows  application  portability  across  heterogeneous  sys¬ 
tems. 

PQSIX  -  Portable  Operating  System  Interface  -  POSIX  and  its  extensions  are  developed  by  IEEE 
1003  and  JTC  1  SC21  WG  15.  Defines  a  standard  operating  system  interface  and  environment 
to  support  application  portability  at  the  source  level. 

POSIX  Guide  -  The  project  of  IEEE  1003.0.  Guide  to  a  POSEX-based  open  systems  architecture. 

SC  subcommittee;  as  a  proper  noun  refers  to  a  standards  subcommittee  in  the  international  arena, 
for  example  SC24  means  IEC/ISO/JTC  1/SC24. 

SC21  JTC  1  SC21  for  Open  Systems  Interconnection 

SC21  WG1  OSI  Architecture 
SC21  WG3  Database 
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SC21  WG4  OSI  Management 

SC21  WG5  Specific  Application  Services 

SC21  WG6  OSI  Session,  Presentation  and  Common  Application  Services,  includes  ASN.l. 

SC21  TAG  U.S.  TAG  to  SC21  •  This  group  is  doing  a  survey  of  DBMS  Related  Standardization 
Activities.  -  not  the  same  as  the  SPARC/DBSSG  Data  Base  Systems  Study  Group. 

SC22  JTC  1  SC22  for  Programming  Languages 

SC22  WG11  Includes  Language  Independent  Datatypes  and  Language  Independent  Proce¬ 
dure  Calling  Mechanisms. 

SC22  WG15  POSIX 

SC22  TAG  U.S.  TAG  to  SC22  -  Technical  Report  on  Binding  Techniques  for  Programming  Lan¬ 
guages  comes  under  this  group. 

SC24  JTC  1  SC24  for  Graphics 

SG-FS  JTC  1  Special  Group  on  Functional  Standardization.  Involved  in  the  process  of  the  adop¬ 
tion  of  International  Standards  Profiles  (ISP). 

SGML  Standardized  Generalized  Markup  Language  for  document  preparation,  storage  and  re¬ 
trieval  of  textual  data.  MIL-M  28001. 

SPARC  Standards  Planning  and  Requirements  Committee,  particularly  X3/SPARC.  Analogous 
to  the  Special  Working  Group  on  Strategic  Planning  (SWG-SP)  within  JTC  1. 

SPARC/ APSG  X3/SPARC  Application  Portability  Study  Group.  A  group  under  X3/SPARC 
studying  application  portability. 

SSI  Software  System  Interface;  either  the  Japanese  SSI  program  or  the  disbanded  studies  in  SSI 
such  as  the  JTC  1  SWG-SSI  and  the  X3/SPARC/SSISG. 

SQL  Structured  Query  Language.  Originally  an  IBM  query  language  for  relational  databases,  it 
has  become  the  industry  standard  as  well  as  an  ANSI  and  ISO  standard.  FIPS  127,  ANSI 
X3.135-1986. 

SVID  System  V  (five)  Interface  Definition.  It  is  used  in  the  phrase  “SVTD  conforming”  meaning 
that  it  has  the  same  interfaces  and  is  thus  compatible  with  System  V  UNIX  from  AT&T.  The 
only  systems  which  really  pass  the  test  are  direct  derivatives  from  AT&T  UNIX. 

SWG-P  JTC  1  Special  Working  Group  for  Procedures 

SWG-SP  JTC  1  Special  Working  Group  for  Strategic  Planning 

TAG /APSG  JTC  1  Technical  Advisory  Group  -  Application  Portability  Study  Group  to  the  JTC 
1  SWG-SP  APSG  (TSG-1) 

TC  Technical  Committee  -  often  used  in  names  of  both  international  and  national  committees,  for 
example  ISO/TC97  and  IEEE  TCOS  (Technical  Committee  on  Operating  Systems) 

TC97  Technical  Committee  97  -  ISO/TC97  has  merged  into  JTC  1 
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TCOS  IEEE  Technical  Committee  on  Operating  Systems,  the  IEEE  committee  which  authorized 
the  standardization  work  on  POSIX  under  IEEE  P1003. 

TSG-1  -  JTC  1  Technical  Study  Group  #1.  The  first  technical  study  undertaken  since  the  for¬ 
mation  of  JTC  1.  Formally,  ISO/IEC/JTC  1/SWG-SP-APSG.  The  Application  Portability 
Study  Group  under  the  auspices  of  SWG-SP. 

WG  Working  Group  -  -  As  part  of  a  proper  noun  “WG”  refers  to  a  working  group  within  a  JTC 
1  subcommittee,  for  example  SC22  WG15.  IEEE  technical  committees(ie:  P1003)  also  have 
working  groups,  (ie:  P10003.5).  However  X3  technical  committees  (ie:  X3H3)  have  task 
groups  (ie:  X3H3.6). 

X  Window  System  X  was  the  first  server  based  window  system.  It  was  developed  jointly  by 
Massachusetts  Institute  of  Technology  (MIT)  and  Digital  Equipment  Corporation(DEC). 

X  Consortium  The  consortium  adopting  both  consensus  and  de  facto  standards  for  the  X/OPEN 
Open  Systems  Environment. 

X/OPEN  A  marketing  organization,  labeling  products  which  comply  with  standards  established 
by  the  X  Consortium. 

X3  Accredited  National  Standards  Committee  -  Information  Technology 

X3H2  The  X3  Committee  for  Database.  TAG  to  SC21  WG3.  Includes  all  work  on  SQL 

X3H3  The  X3  Committee  for  Graphics,  TAG  to  SC  24. 

X3H3.1  >  Programmer’s  Hierarchical  Interactive  Graphics  System  (PHIGS) 

X3H3.2  -  Graphics  Architecture:  Information  Processing  Systems  -  Computer  Graphics  & 
Reference  Model  of  Computer  Graphics 

X3H3.3  -  Virtual  Device  interfaces  -  Computer  Graphics  Interface  (CGI)  &  Computer 
Graphics  Metafile  (CGM) 

X3H3.4  -  Language  Binding  -  includes  PHIGS/Ada,  GKS/Ada,  GKS-3D/Ada.  X/Ada 
would  be  a  new  work  item. 

X3H3.5  -  Graphical  Kernel  System  (GKS);  includes  3  Dimensional  extensions  to  GKS. 
X3H3.6  -  Window  Management;  includes  Display  Management  for  Graphical  Devices 
X3H3.7  -  Validation,  Testing  &  Registration 

X3H3.8  -  Application  Programming  Interface  (API)  for  Imaging  Graphical  Devices  and 
Data-Stream  Encoding  for  Window  Management. 

X3H4  The  X3  Committee  for  Information  Resource  &  Dictionary.  TAG  to  SC21  WG3 

X3H4.1  -  IRDS  Reference  Model 
X3H4.2  •  IRDS  External  Software  Interface 
X3H4.3  -  IRDS  Export/Import 

X3T2  -  The  X3  Committee  for  Data  Interchange.  TAG  to  SC21  WG6  and  to  SC22  WGll. 
Projects  include: 

ASN.l  Information  Processing-  OSI  -  Specification  of  Abstract  Syntax  Notation  One  (ASN.l) 
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Common  Language-Independent  Data  Types 
Language  Independent  Procedure  Calls 

X3T5  -  The  X3  Committee  for  Open  Systems  Interconnection  (OSI)  TAG  to  SC  21  WG6 

X3T5.1  OSI  Architecture  TAG  to  SC21  WGl 
X3T5.4  OSI  Management  Protocols  TAG  to  SC21  WG4 
X3T5.5  Application  and  Presentation  Layers  TAG  to  SC21  WG5 

X12  Accredited  Standards  Committee  -  Electronic  Data  Interchange 
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